task info caps, death, and cap server

[Marcus Brinkmann]

Hi,

(some notes for neal which might also interest other people)

the task death notification manager is a task-global entity (so, you
may receive spurious task death events in your handler, because some
other part of your program might have added that particular task).

I think that is good enough, but in theory you could extend it to have
every handler only be notified about task deaths that this particular
subsystem is interested in.  Then spurious events won't happen.  The
reason this should be good enough is that you will receive task death
notifications the moment you get a task info cap, and this means

A cap bucket will register its own handler in
libhurd-cap-server/bucket-create.c::hurd_cap_bucket_create.

The handler will, as you can verify yourself in the code, lookup the
client, and, if it can find it, inhibit all RPCs and then _end_ all
RPCs (the special state BLACK is used to signal that the client is
really dead now, and any worker thread which was preempted on an
incoming message that it has not yet processed (and thus was not
inhibited yet) should drop its message, instead blocking until the
state goes back to GREEN (as would be the case with state RED).  Then
it will release the last reference for the client.

This will run the code in client-release.c, which will actually clean
up stuff and eventually release the task info cap, at a time where
nothing in the system is using it anymore.  Note that all of this runs
inside the task death notification (it's not strictly necessary, but
allows us to implement polling for task death notifications simply by
returning all dead tasks you have task info caps for, without spinning
if you have not released it yet - it will be released when all
handlers have been processed).

When a new client is added, first task death notifications are
suspended, and then a new task info cap is acquired if needed.  There
is in fact one per bucket (and other interested parties), but that
doesn't matter, because all subsystems will receive the notification,
and release their copy.  Alternatively, the task death notification
manager could manage the task info caps centrally, but I don't see
much of an advantage there.

I just commit a comment fix (the location where task info caps should
be acquired was not pointed out correctly).  Injecting caps into
clients is thus a painless procedure (the handshake protocol can be
readily implemented).

Implementing the cap transfer protocol will be some more fun, but not
exceed the complexity that is already in there.

Thanks,
Marcus