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

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

* 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

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

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

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.

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
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
http://www.memetrics.com/emailpolicy.html