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