Re: OK, lets talk portability. - Mailing list pgsql-hackers

> -----Original Message-----
> From: mlw [mailto:markw@mohawksoft.com]
> Sent: Tuesday, May 07, 2002 7:03 AM
> To: Tom Lane
> Cc: Marc G. Fournier; PostgreSQL-development
> Subject: Re: [HACKERS] OK, lets talk portability.
>
>
> Tom Lane wrote:
> > BTW, I have been able to test the named-semas variant of
> posix_sema.c
> > on OS X, and it works.  I don't have access to any platforms that
> > support unnamed POSIX semas, which is too bad because that
> seems much
> > the preferable variant.  Can anyone check it out?
>
> I did, and yes I was confused. Sorry. Your posix
> implementation assumes that
> only a single process will have access to the semaphore list
> for deletion is
> this correct? I guess I need to know how much access the
> child processes need
> to have to the internal control structures, none? Some? All?
>
> As I embark on my journey back to the dark side, here are my
> concerns for a
> native Windows PostgreSQL. I think it is a whole lot more
> than originally
> thought.
>
> (The Matrix: Do not try to implement the fork() that would be
> impossible,
> instead only try to realize the truth, there is no fork())
>
> Cygwin does a lot of trickery to implement fork(), but it is
> not an OS level
> thing. Without fork() we would have to have a way to start a
> postgres backend
> and send it information about what it should be doing, and
> what it should be
> doing it with.
>
> With no fork(), information that would normally be copied on
> fork() is not
> copied. Therefore, we need to know what that information is and how to
> propagate it to the child process (under windows)
>
> Files, Windows does not have a native open,close,read,write
> ,lseek support.
> Yes, they have some notion of low I/O for compatibility,
> _open, _close, etc.
> but the flags and permissions are not identical. The low file
> API for Windows
> is CreateFile.
>
> Semaphores, and shared memory are easy enough (If have
> written it in different
> forms before), depending on the level of opaqueness to child
> processes.
>
>
> The voice in the back of my head, says we need to define what
> the portability
> issues are:
>
> process control (fork()/spawn() etc.)
> file operations (read, right, open, close, seek)
> IPC constructs (shared memory, semaphores)
> System interface (sync() etc)
>
> Any others?
>
> We should either use Apache's APR and augment it with
> semaphores, or come up
> with a doc which defines how these various things are
> handled. Obviously, it
> will grow as we find things that don't work.

A native port to Win32 has already been accomplished by several groups
(including CONNX Solutions Inc., where I work).
There is also one from Japan:
http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html
I saw some others when I looked around.

Trying to implement fork() is a bad idea, I agree.  We used
CreateProcess instead to launch a new server.

My idea of how portability ought to be accomplished is to leverage what
others have done and use that.

I have done a port of Pthreads to NT, which might be useful for a
threaded version of the server, but I think a better approach would be
to use an OS compatibility layer like ACE.  ACE might also be useful for
web servers and things of that nature.  It may also be possible to
create a server core from ACE that would outperform the PosgreSQL
connection engine.  JAWS (for instance) is a freely available web server
that grotesqely outperforms Apache and the other free ones (which makes
me puzzle about why JAWS is not more popular).  Anyway, here is the ACE
link:
http://www.cs.wustl.edu/~schmidt/ACE.html