Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> File descriptors are all identically structured objects, so at worst you
>>>>>>> ruin some other app's day. But the registry contains arbitrary objects
>>>>>>> with different internal layout. If you start assuming object_a * is
>>>>>>> object_b * and use the pointer etc. included in a as if they have the
>>>>>>> meaning of b, you quickly ruin the kernel's day as well. Therefore,
>>>>>>> native, e.g., does magic checks after fetching from the registry. As I
>>>>>>> said, this test here works differently, but it has the same effect and
>>>>>>> impact.
>>>>>> By the way, would not it make sense to have separate hash tables for
>>>>>> separate objects types ? I mean then we would not need any validation,
>>>>>> and several object types could use the same name.
>>>>> From that POV a good idea. The only issue I see is a management problem:
>>>>> How many mutex, thread, queue, whatever slots do you want in your
>>>>> system? One knob for them all? Or countless knobs for all object types
>>>>> of all skins? That's hairy, I'm afraid.
>>>> xnmalloc, the pool size is the limit.
>>> You mean kind of "xnrealloc", including atomically copying potentially
>>> large descriptor tables over? Sounds not that attractive.
>> No, I mean the hash table contains pointers, and the objects are
>> allocated dynamically...
>
> Handle lookup is not going through hash tables. It's index based (like
> file descriptors).
Ok, but using hash tables instead of static tables allow you to have
more objects in the hash than hash buckets, and a "registry slot"
occupies simply a bit in a multi-level bitfield when free, so you can
have preposterous registry slots limits like 2048 or 4096.
--
Gilles.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
