[haiku-gsoc] Re: Xsi semaphorses: patch #1
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Thu, 17 Jul 2008 14:34:02 +0200
On 2008-07-17 at 15:44:06 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx>
wrote:
> 2008/7/15 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> >> But what if some programs do share IPC keys for different kinds of IPC
> >> subsystems?
> >> Wouldn't that result in a bug from the application POV?
> >
> > I don't see what kind of potential bug you're thinking of.
> >
>
> If it's ok with you, I'd like to investigate a bit more on this before
> removing
> the special case and use an ipc table for each subsystem, because although
> the standard does not say explicitly to use the same ipc table for all
> subsystems
> it does provide an error code for the above situation
>
> [ENOENT]
> A semaphore identifier does not exist for the argument key and
> (semflg &IPC_CREAT) is equal to 0.
>
> and keys gets created on any {sem,msg,shm}get call.
I really don't see how you can interpret this error description to have
anything to do with how the implementation manages the IPC key -> sem ID
mappings. It simply means that semget() has been invoked for an IPC key for
which no semaphore has been created yet (and the call itself is not supposed
to create the semaphore).
You wrote earlier that other systems allow to use the same IPC key for
different IPC subsystems. If we want to do the same in Haiku using a
separate table per subsystem and using a shared table with potentially empty
slots in the entries results in the same external behavior -- it is really
just an implementation detail. One that makes as much sense as using a
common table for BeOS semaphores, ports, and threads IMO.
> Anyway, I've attached a patch that (hopefully) fix all previous issue, and
> also
> (hopefully) add the rest of missing features without any other mistakes.
> It's still not 100% complete though.
Will have a look at it later.
CU, Ingo
Other related posts:
