From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48B5E6E6.10007@domain.hid> Date: Thu, 28 Aug 2008 01:44:38 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <48B5592B.1090005@domain.hid> <48B55F7C.5030901@domain.hid> <48B56685.4060500@domain.hid> <48B56876.3090601@domain.hid> <48B568FD.9010905@domain.hid> <48B56A0C.9060006@domain.hid> <48B56AF6.6080509@domain.hid> <48B56C06.1030808@domain.hid> <48B56D05.6020509@domain.hid> <48B56E69.9000100@domain.hid> <48B56F78.6050405@domain.hid> <48B57046.70207@domain.hid> <48B572D0.2000801@domain.hid> <48B5741D.7050207@domain.hid> <48B5746C.1000201@domain.hid> <48B574BB.4040602@domain.hid> In-Reply-To: <48B574BB.4040602@domain.hid> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [RFC][PATCH 2/3] Switch to handle-based fast mutex owners List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai-core 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.