Re: Other Win32 TODO items?

----- Original Message -----
From: "Claudio Natoli" <claudio(dot)natoli(at)memetrics(dot)com>
To: "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Sent: Saturday, November 01, 2003 3:42 AM
Subject: [pgsql-hackers-win32] Other Win32 TODO items?

>
> 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!
>
> * select(0,NULL,NULL,NULL,&delay) doesn't, under Win32
> - replace with Sleep for win32?
>
> * Directory "slashes"
> - still quite a large number of forward slashes all over the place
>

Win32 seems to be quite happy with forward slashes. That's why I
canonicalised all paths to use them in initdb. I tested this using mingw
shell, cygwin shell and XPHE standard command shell.

> * 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".
>

In initdb I didn't even do a stat check for executable bit on windows, as I
already knew I was stat-ing a .exe.

> * 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

I had not noticed this (wasn't checking errno, just using code like
while ((file = readdir(dir)) != NULL)

>
> * 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).
>

ugghh!

> 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 :-(
>

This needs further diagnosis IMHO.

>
> 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.
>

Do we need to talk to the MinGW people about this?

> Cheers,
> Claudio
>
> ---
> WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS:
> THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041
> TEL: +61 2 9555 1544 FAX: +61 2 9555 6911

(waves across american continent and pacific ocean in direction of homeland
;-)

cheers

andrew