Re: reuse of task IDs

[Espen Skoglund]

[Peter De Schrijver]
> On Mon, May 05, 2003 at 08:32:52PM +0200, Marcus Brinkmann wrote:
>> On Mon, May 05, 2003 at 07:49:43PM +0200, Peter 'p2' De Schrijver wrote:
>>> Marcus,
>>> 
>>> Wouldn't it be much easier if L4 supported the session concept ? I
>>> mean L4 actually knows when a thread dies and it could invalidate
>>> all sessions with this thread...
>> 
>> What is a session?
>> 
>> If you mean that L4 should support some form of ports, well, then
>> I'd think that the L4 designer will respectfully disagree :) Their
>> IPC is truly minimal, but that is the reason it is so fast.  If you
>> look at my proposal, you will see that in the most often used RPCs
>> (simple message with no object handles), we can preserve this
>> maximum performance without loss.
>> 

> A session in this case would be a series of messages which flow
> between 2 endpoints which cannot change during the session
> lifetime. If one of them would die, the session dies. Now, anyway.

Well, first of all you would have to get all the semantics with this
session stuff right.  How do you specify sessions?  When are sessions
terminated?  Do you use some form of session IDs?  If so, how do you
choose a session ID?  Can session IDs be "faked"?  Etc., etc.

After clearing this out you would then most likely have introduced a
completely new concept into the kernel.  Care must then be taken so as
to not also introduce extra policy in the kernel.

Finally you would have to implement this new feature efficiently, and
from my initial thinking about it, I believe that introducing this
session stuff opens a huge can of worms that can not readily be
handled without loads of checks and special cases.

Now, once you have designed and implemented this session handling you
might have a kernel that fits "nicely" with Hurd, yes.  On the other
hand, doing session handling in the kernel will possibly have a
tremendous impact on IPC performance (including IPC cache footprint).
The question is then: Was it worth it?  My response would be: Probably
not.  You would have extra crud in the kernel, crud which could almost
as easily be implemented on user-level.

(Of course, having no real model for session handling, my thoughts
above are all speculation.)

> Another solution would be versioning.  but we already use that field
> and it's on the small side anyway. We could add our own version in
> the message data but that would likely kill very fast IPC because of
> the message size.

If you're concerned that adding an extra word in the message will kill
the IPC performance, a quick glance at

   http://l4ka.org/projects/pistachio/ia32/perf.php

will tell you that message transfer of up to 63 untyped words scales
reasonably well on L4Ka::Pistachio (a result of the new API).

        eSk