Re: darwin pgsql patches

At 1:31 AM -0500 12/5/00, Tom Lane wrote:
>Peter Bierman <bierman(at)apple(dot)com> writes:
>> Q2) As I'm 95% done making it work as a shim, I notice that the Sem
>> stuff is shimmed in Postgres also, and I wonder if there'd be
>> objections to me conditionalizing it there. It would be a LOT easier
>> to change the InternalIpc...() to use POSIX named semaphores vs my
>> current route of implementing SysV semaphores as a shim on top of
>> POSIX ones.
>
>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. Darwin has the POSIX API, and not the SysV API, and PG uses the SysV API. I'm implementing the SysV API for PG as a shim on top of the POSIX API.

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. PG doesn't use any of the fancy features of the SysV API, just create, set, release, and inspect.

>
>> Also, one of the things that got me into a mess is that the postmaster
>> allocates some sem arrays via semget(), and then lets its children use
>> the semids that were returned in the parent process. I can't find any
>> docs that say this is legal, though obviously it must work. The
>> Vahalia book on Unix Internals describes implementation that explains
>> *why* it works, but sort off alludes that it shouldn't.
>
>Nonsense. HPUX's semget() man page says:
>
> ... This call creates a new identifier,
> subject to available resources. The identifier is never returned
> by another call to semget() until it has been released by a call
> to semctl(). The identifier should be used among the calling
> process and its descendents; however, it is not a requirement.
> The resource can be accessed by any process having the proper
> permissions.
>
>I'd say that makes it perfectly clear that semaphore identifiers are
>system-wide, and *certainly* makes it clear that a semid may be passed
>down to child processes.

Yup. Like I said, I couldn't find anything that said it was legal. That's why I asked, and you kindly provided the proof that it was. I figured it must be, since it's obviously working for PG on a dozen or more platforms, but it seemed odd.

In any case, my problem is that darwin doesn't currently have any similar construct. I can't create a semaphore that can be transparently passed to a child while in use. I can create a named semaphore that children can open when they want it, which will work the same way. But to preserve PG's semid semantics, I have to do a lot of goofy hacks in my shim to keep track of semids across processes. It would be easier to just move up a level in the stack and change PG's shim to use POSIX API.

After all, someone had the foresight of giving PG a shim for Semaphores, might as well use it!

-pmb

--
"Every time you provide an option, you're asking the user to make a decision.
That means they will have to think about something and decide about it.
It's not necessarily a bad thing, but, in general, you should always try to
minimize the number of decisions that people have to make."
http://joel.editthispage.com/stories/storyReader$51