Date: Tue, 05 Dec 2000 10:58:15 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Bierman <bierman@apple.com> writes:
>> POSIX IPC isn't compatible with SysV IPC? News to me. Chapter and
>> verse, please?
> Didn't say that. They're just two different APIs for doing semaphores.
I'm still startled. Why would the POSIX guys have invented their own
API, rather than standardizing on the well-entrenched SysV IPC calls?
They did not have a charter to invent new stuff.
The POSIX semaphore interface comes from the pthreads work. In my
opinion, the System V IPC calls are badly designed. I haven't done
much work with POSIX semaphores, but they are simpler and more
efficient to implement.
> Since PG uses it's own shim to go from internal functions to the SysV
> API, I'm asking if there'd be objection to me implementing the
> conditional code in src/backend/storage/ipc.c, having PG's shim use
> POSIX API directly.
No objection here, but I wonder whether you'll find that it helps.
The ipc.c code is so thin that it doesn't really hide any SysV
semantics. In particular, it will not help you to hack ipc.c if your
problem is that child processes don't inherit access to semaphores
created by their parent. (But that would be so impossibly brain-dead
that I do not believe it...)
Believe it. Having semaphores be shared between processes is optional
when using POSIX semaphores. GNU/Linux, at least with glibc 2.1, does
not implement sharing semaphores between processes.
However, on systems which do fully implement POSIX semaphores, it
should be easy for Postgres to use them. They should be created in
the shared memory segment.
Ian
