Re: HEADS UP: Win32/OS2/BeOS native ports

> "Igor Kovalenko" <Igor(dot)Kovalenko(at)motorola(dot)com> writes:
> > What really need to be done is new abstraction layer which would cover
SysV
> > API, POSIX and whatever native APIs are better for BeOS/OS2/Win32. I
almost
> > did it last time...
>
> Yes. I just sent off a proposal for a cleaner semaphore API --- please
> comment on it.
>

I will look. I remember from my last attempt that it actually did not
involve a lot of changes in your existing abstraction layer (which already
exists, just being SysV-centric). I believe only one function prototype had
to be changed... Your proposal sounds like more changes will be needed...

> My inclination is to stick with the SysV API for shared memory, however.
> The "stickiness" is actually not a bad thing for us in the shared memory
> case, because it allows a new postmaster to detect the situation where
> old backends are still running: it can see that there is an old shmem
> segment still present with attached processes. Without that, we have no
> good defense against the scenario where an old postmaster dumped core
> leaving backends still running. The backends are fine as long as they
> are left to finish out their operations, or even killed with whatever
> degree of prejudice the admin wants. But what we must *not* do is allow
> a new postmaster to start while the old backends are still running;
> that would mean two sets of backends running without contact with each
> other, which would be fatal for data integrity. The SysV API lets us
> detect that case, but I don't see any equally good way to do it if we
> are using anonymous shared memory.

It does not have to be anonymous. POSIX also defines shm_open(same arguments
as open) API which will create named object in whatever location corresponds
to shared memory storage on that platform (object is then grown to needed
size by ftruncate() and the fd is then passed to mmap). The object will
exist in name space and can be detected by subsequent calls to shm_open()
with same name. It is not really different from doing open(), but more
portable (mmap() on regular files may not be supported).

I suggest we do IPC abstraction which would cover shared memory as well as
semaphores, otherwise it will be only half of solution - platforms without
SysV API would still have to emulate SysV shared memory.

-- igor