> -----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

Tue, 7 May 2002 10:36:19 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: OK, lets talk portability.
Dann Corbit wrote:
> 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.

It is the license issues, I think. 
> 
> Trying to implement fork() is a bad idea, I agree.  We used
> CreateProcess instead to launch a new server.

That's my big issue, fork() is important to postgres because it assumes all the
child's global and static variables will be a copy of what was in the parent,
as well as system resources being cleaned up.

Think about file handles, they have to be tracked and handled on a process
level. The entire dynamic and static data memory area would have to be copied.
Memory pointers allocated with "malloc()" would also have to be valid in the
child, which means that the heap would have to be copied too. So, in short, the
whole data area.

I think abandoning cygwin will require more work than is justified, we would
just end up rewriting it. So, if we are going to require cygwin or something
like it, then I think we should spend our efforts to profile and optimize the
cygwin version.

I guess it comes down to the reason why we intend to get rid of the requirement
of cygwin on Windows. If it is performance, we may be able to spot optimize the
code under cygwin, and improve performance. If it is a license issue, then that
is not a technical discussion, it is a legal one. Actions we take to remove a
cygwin requirement, in the license case, are probably of limited technical
merit, but of creating code (which probably already exists) for the PostgreSQL
project with a license we can live with.

Tue, 07 May 2002 16:41:57 -0400
mlw <markw@mohawksoft.com>
Re: OK, lets talk portability.
Le Mardi 7 Mai 2002 22:41, mlw a écrit :
> I think abandoning cygwin will require more work than is justified, we
> would just end up rewriting it. So, if we are going to require cygwin or
> something like it, then I think we should spend our efforts to profile and
> optimize the cygwin version.
>
> I guess it comes down to the reason why we intend to get rid of the
> requirement of cygwin on Windows. If it is performance, we may be able to
> spot optimize the code under cygwin, and improve performance. If it is a
> license issue, then that is not a technical discussion, it is a legal one.
> Actions we take to remove a cygwin requirement, in the license case, are
> probably of limited technical merit, but of creating code (which probably
> already exists) for the PostgreSQL project with a license we can live with.

There is other issues :

1) Cygwin installation.

Presently, Cygwin installer is a nice toy but it is primarily designed for 
hackers. In order to install PostgreSQL, you need to install a minimum set of 
packages. As no real dependency between packages exist, a newbee will not 
know which packages should be downloaded and which should not. Also, Cygwin 
installer does not allow the automatic installation of PostgreSQL within a 
service.

The result is that newbees eather download ***all*** Cygwin packages or simply 
say no. Furthermore, after installation, people are facing another issue 
which is the Unix world. Users have a hard time understanding that PostgreSQL 
configuration is stored in /var/lib/pgsql/...

So my personal opinion is that if PostgreSQL relies on the present Cygwin 
version, it has no chance to get a standard solution under Windows.

2) Cygwin static implementation

When I contacted Cygwin team, they said there used to be a static version of 
Cygwin which is no longer maintained. They also told me there was little work 
to get it working again. Maybe you could fork a Cygwin static version into a 
dll. This may sound as a ***bizarre*** idea, don't flame me, but they 
PostgreSQL would only depend on this dll with static Cygwin built-in.

3) Existing version of PostgreSQL under Windows
Did anyone test http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html

Cheers,
Jean-Michel POURE


Wed, 8 May 2002 10:37:08 +0200
Jean-Michel POURE <jm.poure@freesurf.fr>
Re: OK, lets talk portability.