[haiku-gsoc] Re: Xsi semaphorses: patch #1
- From: "Salvatore Benedetto" <emitrax@xxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Tue, 15 Jul 2008 21:14:13 +0000
2008/7/14 Ingo Weinhold <ingo_weinhold@xxxxxx>:
>
>> > + size_t HashKey (const key_t key) const
>> > + {
>> > + // TODO: Define a better hash function
>> > + // key_t is a 32 bit integer value.
>> > + return (size_t)(key & 0x00000fff) % 32;
>> >
>> > How about the obvious: "return (size_t)key"?
>>
>> Because it's not obvious to me.
>
> Mmh well, at least you used it for the other hash table.
Because in the other hash table the key is a very low value that actually
starts from 0.
>
> The returned hash value is not directly used as index. The hash table applies
> a modulo first.
Ok, thanks.
>> I plan to move the IPC code to its own source file and extend its
>> usage for message queues
>> and shared memory. I know we already talked about it and decided to
>> use 3 different tables
>> but I don't really see the point of that, besides other OSes don't
>> seems to do so.
>
> One obvious point of using different tables is right here: It avoids special
> cases. Another is that, since the standard is not very explicit in this
> respect, I expect most programs not to share IPC keys for the different kinds
> of IPC subsystems. So you would end up with table entries that potentially
> reference three kinds of IPC objects, but actually reference only one.
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?
Regards,
--
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer Engineer
University of Pisa
www.haiku-os.it
Other related posts:
