Re: 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.