[haiku-gsoc] Re: [HCD]: xsi semaphore - kernel side

On 2008-06-17 at 18:21:20 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx> 
wrote:
> 2008/6/15 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> >
> > On 2008-06-15 at 23:26:45 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx>
> > wrote:
> >>
> >> time for me to use this mailing list.
> >>
> >> I'm looking at the current implementation of haiku semaphore and I see 
> >> that
> >> during boot a few pages, it depends on the number of semaphore, is 
> >> allocated
> >> in order to store semaphore slots. I guess for performances reason.
> >>
> >> Now I'm wondering if I should do the same for the xsi semaphore, even 
> >> though
> >> only ported application (currently none) will used it, or create them run
> >> time
> >> when I needed? The latter would avoid waisting a few MB of probably
> >> unneeded memory
> >> when xsi semaphore are not used.
> >
> > Please just use a hash table (key_t -> semaphore object).
> 
> Ok. The only thing I haven't understand with the standard yet though,
> is whether the key_t table
> should be shared among IPC primitives (semaphore, message queue, shared 
> memory)
> or if I have to declare one for each primitives.

I haven't seen the standard mentioning anything in this regard, so I'd use 
separate hash tables.

> > Regarding key_t, I believe it should be defined to a 64 bit integer type.
> 
> It is actually defined as long (open solaris), or 32 bits integer type 
> (linux).
>
> > ftok() should probably return ((<node ID> << 8) | (id & 0xff)). This is 
> > far
> > from perfect, since we cannot guarantee that the IDs are unique this way, 
> > but
> > I think it's the best we can do, since key_t needs to be an integer type 
> > and
> > we've got 71 bits of information to encode.
> 
> Honestly I've just used the same implementation as all the other OS,
> since it is basically
> the same among all of them
> 
> key_t
> ftok(const char *path, int id)
> {
>     struct stat st;
> 
>     if (stat(path,&st) < 0)
>         return (key_t)-1;
> 
>     return (key_t) (id << 24 | (st.st_dev & 0xff) << 16 | (st.st_ino & 
>     0xffff));
> }
> 
> I haven't test it yet though.

If all other OSs are doing it this way, then I suppose we can do that as 
well. By using only 16 bit of the node ID, it's not very hard trying to 
adhere to the standard, though:

"The ftok() function shall return [...] different key values when called with 
different id values or with paths that name different files existing on the 
same file system at the same time."

CU, Ingo

Other related posts: