Skip site navigation (1) Skip section navigation (2)

Re: Other Win32 TODO items?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
Cc: pgsql-hackers-win32 <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Other Win32 TODO items?
Date: 2003-11-11 04:02:49
Message-ID: 200311110402.hAB42n913766@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers-win32pgsql-patches
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(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2003-11-11 05:33:09
Subject: Re: sigpipe handling
Previous:From: Bruce MomjianDate: 2003-11-11 03:53:09
Subject: Re: Other Win32 TODO items?

pgsql-hackers-win32 by date

Next:From: Marsh RayDate: 2003-11-11 12:22:25
Subject: Re: Committing Resources to Win32
Previous:From: Bruce MomjianDate: 2003-11-11 03:53:09
Subject: Re: Other Win32 TODO items?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group