> -----Original Message-----
> From: mlw [mailto:markw@mohawksoft.com]
> Sent: Tuesday, May 07, 2002 7:58 AM
> To: Marc G. Fournier
> Cc: Tom Lane; PostgreSQL-development
> Subject: Re: [HACKERS] OK, lets talk portability.
> 
> 
> "Marc G. Fournier" wrote:
> > 
> > On Tue, 7 May 2002, mlw wrote:
> > 
> > > Tom Lane wrote:
> > > > And no, I don't want to undo those changes.  Especially 
> not if the
> > > > only reason for it is to not have to use Cygwin on 
> Windows.  Most
> > > > of these changes made the startup code substantially simpler,
> > > > faster, and more reliable.
> > >
> > > Then I think the notion of a pure Windows version is dead 
> in the water.
> > > Writing a fork()-like API for Windows is, of course, 
> doable as evidenced
> > > by cygwin, and from a general theory seems like a pretty straight
> > > forward thing to do (with a few low level tricks of 
> course) but the
> > > details are pretty scary.
> > 
> > How is Apache doing this?  I believe they do allow the 
> pre-forked model to
> > work, so how are they getting around those limitations?
> 
> Apache and PostgreSQL are quite different in their 
> requirements of shared
> memory. Apache (2.x) simply uses CreateProcess and passes 
> duplicate file
> handles.

The way to make CreateProcess() work for PostgreSQL is very simple.

By the time of the fork(), not much has been done.  Some needed
calculations can simply be stored into shared memory (which is trivial
to implement).  Some other tasks can simply be executed by the cloned
process, exactly as they were executed in the server.

Using fork() on Win32 is pointless, hopless, awful.  Don't even think
about it.  It's a death warrant.

Tue, 7 May 2002 11:26:17 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: OK, lets talk portability.
Dann Corbit wrote:
> 
> > -----Original Message-----
> > From: mlw [mailto:markw@mohawksoft.com]
> > Sent: Tuesday, May 07, 2002 7:58 AM
> > To: Marc G. Fournier
> > Cc: Tom Lane; PostgreSQL-development
> > Subject: Re: [HACKERS] OK, lets talk portability.
> >
> >
> > "Marc G. Fournier" wrote:
> > >
> > > On Tue, 7 May 2002, mlw wrote:
> > >
> > > > Tom Lane wrote:
> > > > > And no, I don't want to undo those changes.  Especially
> > not if the
> > > > > only reason for it is to not have to use Cygwin on
> > Windows.  Most
> > > > > of these changes made the startup code substantially simpler,
> > > > > faster, and more reliable.
> > > >
> > > > Then I think the notion of a pure Windows version is dead
> > in the water.
> > > > Writing a fork()-like API for Windows is, of course,
> > doable as evidenced
> > > > by cygwin, and from a general theory seems like a pretty straight
> > > > forward thing to do (with a few low level tricks of
> > course) but the
> > > > details are pretty scary.
> > >
> > > How is Apache doing this?  I believe they do allow the
> > pre-forked model to
> > > work, so how are they getting around those limitations?
> >
> > Apache and PostgreSQL are quite different in their
> > requirements of shared
> > memory. Apache (2.x) simply uses CreateProcess and passes
> > duplicate file
> > handles.
> 
> The way to make CreateProcess() work for PostgreSQL is very simple.
> 
> By the time of the fork(), not much has been done.  Some needed
> calculations can simply be stored into shared memory (which is trivial
> to implement).  Some other tasks can simply be executed by the cloned
> process, exactly as they were executed in the server.
> 
> Using fork() on Win32 is pointless, hopless, awful.  Don't even think
> about it.  It's a death warrant.

Preaching to the choir my friend.

Tue, 07 May 2002 17:48:30 -0400
mlw <markw@mohawksoft.com>
Re: OK, lets talk portability.
Just a note:

Apache 2.0.36 just released and this is in the release notes:

  *) Deprecated the apr_lock.h API. Please see the following files
     for the improved thread and process locking and signaling: 
     apr_proc_mutex.h, apr_thread_mutex.h, apr_thread_rwlock.h,
     apr_thread_cond.h, and apr_global_mutex.h.  [Aaron Bannert]

Chris

> > By the time of the fork(), not much has been done.  Some needed
> > calculations can simply be stored into shared memory (which is trivial
> > to implement).  Some other tasks can simply be executed by the cloned
> > process, exactly as they were executed in the server.
> > 
> > Using fork() on Win32 is pointless, hopless, awful.  Don't even think
> > about it.  It's a death warrant.
> 
> Preaching to the choir my friend.


Wed, 8 May 2002 09:57:23 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: OK, lets talk portability.