Re: OK, lets talk portability.

"Marc G. Fournier" wrote:
>
> On 7 May 2002, Hannu Krosing wrote:
>
> > On Tue, 2002-05-07 at 15:31, Tom Lane wrote:
> > > mlw <markw(at)mohawksoft(dot)com> writes:
> > > > In the current CVS directory, there is pgsql/src/backend/port directory.
> > >
> > > > I propose that this become a separate subproject and library.
> > >
> > > Right offhand, that seems a pointless exercise in relabeling code that's
> > > going to be the same either way. What's the actual value?
> > >
> > > > The reason I want this is because the semaphore support, specifically
> > > > multiple semaphores identified by a single key, has to be implemented
> > > > with shared memory and multiple semaphores. (Under Windows)
> > >
> > > I think you are confusing issues that are now private to the SysV sema
> > > implementation with things that you really need to do for Windows.
> > > Take a look at port/posix_sema.c for a less cluttered view of the
> > > semantics you actually need to support. (I don't suppose there's any
> > > chance that Gates & Co support POSIX semas, leaving you with no work?)
> >
> > A quick google search acme up with
> >
> > http://sources.redhat.com/pthreads-win32/announcement.html
>
> Damn ... doesn't implement fork(), but does implement semaphores :)
> Sooooo close :)

Windows has semaphores, and looking at Tom's API, this is the least of our
problems.

If we can come up with a fork() free PostgreSQL, the rest is easy.

We need to come up with a set of macros and function API that handle:

Native file operations.
Process control
Shared memory, semaphores, and other IPC
Sockets (Some Windows specific crap will need to be written, but the berkeley
API is fine)
System interface, sync(), fdatasync() and such.