bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emulating no-senders notifications in L4?


From: Thomas Bushnell, BSG
Subject: Re: emulating no-senders notifications in L4?
Date: 12 Nov 2001 16:35:44 -0800
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Farid Hajji <farid.hajji@ob.kamp.net> writes:

> Could you please point at the files/functions that depend on
> no-senders notifications?

First, why we need them: 

We need to allow file servers (and other servers too) to deallocate
resources when there will be no further sends to a given port.  In the
usual case, these are things like memory resources and internal data
structures.  Sometimes it's an entire file on disk: for example, when
a file is removed, it's contents are not deleted until the last open
user of the file goes away.

Now, why they have to be provided by the kernel (or other trusted
source):

When a task dies, its resources need to be all cleaned up.  If it's
the last task with the right to send to that port, then a no senders
notification should be sent.  If we rely on the task to do so itself,
then sometimes it will not happen due to task misbehavior.

> Put another way: you always have "send-rights" to any "port" that is
> listening to messages.

What establishes the existence of a port?

What prevents people from sending messages to ports when they
shouldn't be allowed to?

> 1. The only entity that is allowed to hand out TIDs (a.k.a ports) to
>    clients will be a user-land port-rights server task. (pr-server).

Expensive I would expect.  Isn't that a whole nother two context
switches everytime a port is created?

> 3. A client can explicitely relinquish a send-right by notifying the
>    pr-server about it. The pr-server will update its state and
>    notify whoever registered with it for no-senders notifications if
>    necessary.

Right now there are some assumptions that a no-senders notification is
properly synchronized with users of the port.  The kernel guarantees
that a no-senders notification will be the last message received on a
port (in the usual case).  A misbehaving client could violate this
rule under the description you have (it could lie, claiming
relinquishment, and then go on to send another message).  I suspect
that cleaning up that assumption would not be too much work.

> 4. Since there is no way to reliably/synchroneously detect the crash
>    of a potential IPC sender (a client), the pr-server will need to
>    regularly poll the clients that got send-rights. This can be
>    done somewhat like this:

Something already needs to keep track of process death anyway, so if
L4 doesn't provide that, whatever does can clean the ports too.

But I fear that this kind of polling is going to be expensive.  Why
can't the kernel just send a message when a task dies?  That's a lot
more efficient than a polling mechanism.  (Incidentally, this is the
principal use of dead-name notifications in the Hurd right now, to
detect when a task goes away.)

> This is an awkward way to do it, especially because it is not synchroneous.
> Sure, most of the time, clients will synchroneously relinquish send-rights
> (case 3.) so we get reasonably quick responses. The problem is with
> crashing clients etc...

Yeah, that's what I noted under #3.

> The biggest problem however is one of performance. Since IPC performance
> is so critical, this pr-server stuff adds quite a lot of overhead to
> a very common operation. This is the reason that it would be very
> useful to think of other ways in the Hurd itself (if possible).

Can you propose one?

The problem here (which the abortive Fluke project also failed to
note) is that a *global* conception needs to go on in the minds of
microkernel designers.  Yes, not counting references can make things
faster.  But in the actual world of providing services to users, some
kind of GC simply must happen.  If it's not in the kernel, it's
elsewhere, and often it's much more expensive to provide it elsewhere.

Thomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]