> mlw <markw@mohawksoft.com> writes:
> > I think that you should create a verbatim implementation of the SysV
> > shared memory API in native Win32. It may have to be a pgsysvshm.dll
> > or something like it, but I think it is the best possible approach.
>
> > Let me look at it, I may be able to have something pretty quick.
>
> The notion of redesigning the internal API shouldn't be forgotten,
> though. I'm not so dissatisfied with the shmem API (mainly because
> it's only relevant at startup; once we've created and attached the
> shmem segment, we're done worrying about it). But the SysV semaphore
> API is really kind of ugly, and the ugliness doesn't buy anything except
> porting difficulty. Moreover, putting a cleaner API layer there would
> make it easier to experiment with cheaper semaphore primitives, such
> as POSIX mutexes.
>
> There was a thread last fall concerning redesigning that code --- I've
> forgotten the guy's name, but IIRC he wanted to make a port to QNX6,
That would be me.
> and the sema code was getting in the way. We put the work on hold
> because we were getting close to 7.2 release (or thought we were,
> anyway) but the project ought to be taken up again.
>
Yes, I am intended to give it another spin soon. I think it is bad idea to
impose SysV ugliness on systems which have better solutions. Main problem
with SysV primitives is that they are 'sticky' (i.e., not cleaned up if
process dies/exits by the system). So Postgres has to deal with issues like
discovering leftovers, finding unused IPC keys, etc. It is inelegant and
takes up lot of code. POSIX primitives are anonymous and cleaned up
automatically. So you just say 'give me a semaphore' and you get it, nothing
gets into your way.
Performance of POSIX mutexes and semaphores (on platforms where they are
implemented properly) is also better than SysV semaphores. Unfortunately
some systems have rather lame POSIX support, for example semaphores and
mutexes can't be shared across processes on Linux. That's basically the
reason why people keep sticking to SysV.
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...
-- igor
