Re: Other Win32 TODO items? - Mailing list pgsql-hackers-win32
From | Bruce Momjian |
---|---|
Subject | Re: Other Win32 TODO items? |
Date | |
Msg-id | 200311110402.hAB42n913766@candle.pha.pa.us Whole thread Raw |
In response to | Other Win32 TODO items? (Claudio Natoli <claudio.natoli@memetrics.com>) |
List | pgsql-hackers-win32 |
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@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
pgsql-hackers-win32 by date: