Re: Other Win32 TODO items?

Claudio Natoli wrote:
>
> Hi all,
>
> Following Andrew Dunstan's recent post, thought I'd mention a few other
> things which I think will need to be considered for the Win32 port. I've run
> into these in trying to get a single-process, multi-threaded version of
> postgres to run on Win32. Clearly, if core developers concur, I don't mind
> putting my hand up to provide patches for some or all of them... but I'll
> need advice from core for (at least) the last two.
>
> In rough order of annoyance:
>
> * ioctlsocket_ret
> - is not initialized to 1 (at least in the WIN_32 code I started
> with!)
> - ok, so big deal!

Fixed.

> * select(0,NULL,NULL,NULL,&delay) doesn't, under Win32
> - replace with Sleep for win32?

On TODO.

> * Directory "slashes"
> - still quite a large number of forward slashes all over the place

On TODO.

> * stat() + extension differences
> - execute bits returned by stat are based on file extension under
> Win32
> - therefore, binaries'll need to have .exe extension (ie. no symlink
> for postmaster), and the calls to stat'll have to append ".exe".

Fixed.

> * readdir()
> - sets errno on "final" call (at least in mingw 3.1)
> - mingw source code appears to have been corrected in latest
> revision (1.4) of mingw / runtime / mingwex / dirent.c
> - currently gets things like SlruScanDirectory and MoveOfflineLogs
> really unhappy, but can be dealt with till the next mingw is available

We will just use the updated MinGW when it is released. Added to TODO.

> * pipe() replacement
> - call is available under Win32, and returns "file" handle
> - however, cannot select() on a file handle under Win32 (only socket
> handles)
> - this is a problem in code where postgres may be required to wait
> on a pipe handle and a socket simultaneously (for instance,
> pgstat_recvbuffer).

Added to TODO.

> unlink() + rename()
> - appears the "loop until unlinked" version of pgunlink can cause
> infinite looping
> - rename() has the same problem
> - with my hacked version, I've had cases where unlink is invoked
> which "loops" forever in pgunlink because an open connection still has that
> file handle open (of course, this might be cause of something I've messed up
> in my changes, but the little checking I've performed suggests that this is
> probably not the case).
> - FWIW, this prompted my "Dumb unlink question" of two days ago
> (http://archives.postgresql.org/pgsql-hackers-win32/2003-10/msg00029.php)
> which was so dumb that no one responded :-(

Added to TODO.

> That's about the worst of it. For anyone interested, the multi-threaded
> hacks I've done have produced a win32 postgres which is approaching the
> state needed to be good enough for my work's internal purposes...
>
> However, in doing so, it has become all too clear that, at least until MingW
> supports the __declspec(thread) directive, this is not the approach that
> ought to be taken.

Agreed.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073