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:

Previous
From: Bruce Momjian
Date:
Subject: Re: Other Win32 TODO items?
Next
From: Marsh Ray
Date:
Subject: Re: Committing Resources to Win32