Other Win32 TODO items?
От | Claudio Natoli |
---|---|
Тема | Other Win32 TODO items? |
Дата | |
Msg-id | A02DEC4D1073D611BAE8525405FCCE2B027FE4@harris.memetrics.local обсуждение исходный текст |
Ответы |
Re: Other Win32 TODO items?
(Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Other Win32 TODO items? (Bruce Momjian <pgman@candle.pha.pa.us>) Re: Other Win32 TODO items? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers-win32 |
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
В списке pgsql-hackers-win32 по дате отправления: