Re: task death notifications

[Marcus Brinkmann]

On Sun, May 04, 2003 at 11:38:38PM +0200, Niels Möller wrote:
> I think the natural way to get the (iii)-type updates right, is to
> request a thread death notification whenever a new port right is
> *created* as the result of an operation of type (i) and (ii).

Yow, that's right!  I completely forgot about that.  At some point I will
have to write this all down, so I don't keep forgetting things ;)

This changes everything.

> On Mach, we have "port death notifications" and "no senders
> notifications". When servers manage their own port rights, it seems
> these can be unified, the server needs to get "sender death
> notifications" in some way or the other. When such a notification is
> received, the sender count for the corresponding port can be
> decremented, and when it reaches zero, a "no senders" event can
> be generated internally in the server.

It's not really tied to the Mach notifications, I think.  We still can use
port death and no senders notifications, but they are just callbacks in the
server called by the library implementing ports at the server side.
Task death notifications will indeed be used to decrement send rights.  And
they will also have to be used to cancel pending requests from that task.
In Mach, this can be implemented entirely within the ports system.  On L4, I
think it will be a bit different, for performance and also because we have
to avoid a DoS attack in the current Hurd where you can use any port as a
reply port (and the server can not track who owns it).  I can justify this
because reply ports are usually special anyway (they get special treatment
in glibc, they are usually send once rights, and so on).
 
There is another type of notifications: dead name.  This lets a client know
that a port it has a send right for just died.  This is of course
implemented by the server.

> I'm afraid this gets simpler of all port rights are associated to
> *threads*, not tasks, but I guess we'd rather not do that. And then it
> seems thread death requires a different and more fine grained
> notification than task death.

In the Hurd, we need to tie a port send right to a task.  However, the port
id will be global and contain the server thread responsible for receiving
messages and a unique object id.

We don't need to care about threads.  It's correct that we could track a
thread we have to reply to, but we can just as well use the task only. 
After all, it is just important that we connect to the user's resources in
some way, it doesn't need to be the most exact one.  A superuser would kill
a task anyway to disconnect the user from a server, he would not aim at a
thread.

In other words: We can use one task death notification for all purposed
where the server needs to keep track of a client.

Now, scrap my original mail, it's obsolete.  We will tie task death
notification into the port send right transmission protocol.  I wanted to
take another look at that one anyway, and I am confident that we can tie it
in there in a robust and elegant way, as the receiving side of the handle
needs to contact the server anyway to establish the handle (otherwise a
malicious task could just donate send rights to other processes at will and
die, thus keeping the port alive forever - on the other hand, if a handle is
returned from the server, it does so along an already established
connection, and nothing additional is necessary).

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/