task info caps

[Marcus Brinkmann]

At Thu, 07 Oct 2004 22:14:12 +0200,
Marcus Brinkmann wrote:
> 
> I am also getting more confident that full blown "task info"
> capability items for watching task deaths are superfluous, and that a
> simpler implementation is feasible (just declaring which tasks you
> want by listing their IDs as numbers).

Ok, some details are only coming back to me now.

One nice thing about using task info caps is that they fall into a
generic framework, where you have capabilities, and then a form of
notification procedure (in fact, polling procedure as we found out) to
get informed about any capabilities you hold to dead objects in the
server.  Ie, a task info cap would be defined as a dummy object that
dies when a task dies.  Then a holder of a task info cap receives a
generic capability object died notification for the task info cap and
can use that as an indication that the task object died.

Exactly the same mechanism can then be used for other servers and
other capability objects.  I think we need this anyway, not just for
task info caps, so it's the same code.

So, the task info cap model was actually deeper and more useful than I
remembered two days ago.  And I think I overestimated the overhead of
using real capabilities two days ago, and that using real caps is
actually more useful (you only need one task info cap object for every
task, for which then caps are given out to any watcher).

The "interface" to task info caps would then just create of common
capability functions:

* task_get_task_info (task_t my_task, task_id_t task_id,
                      out task_info_t task_info);
  Get a new task info cap for task_id.
* cap_server_wait_for_dead_caps (cap_server_t root, out: cap list)
  The root object is a root object for the server - for additional
  security we might require some authentication before you can
  actually use this interface, but I don't think it is required.  This
  is a blocking call that will return when any capability object you
  have a capability for died.
  This RPC will be transparently handled by libhurd-cap-server.
  (There is room for optimization here, btw, by including the ability
  to drop task info cap references in an in-parameter to this RPC, so
  you can simultaneously drop dead task info cap refs and wait for the
  next notification, to reduce the number of RPCs made).

The advantage of using such a generic solution is also that all the
right things will automatically happen at fork() when all capabilities
are cloned etc.

This looks immediately useful for other servers beside task, but look
again: The client needs one thread per server to poll for these
notifications (or it needs to poll with timeouts in a round-robin
fasion which sucks a bit).  Threads are cheap, but it's questionable
if we want such an inflation.

I don't remember right now if we decided that we need such dead
notifications for other capability objects in general.  I think I
might have come to the decision that we don't need them at all except
for task deaths, but I'll have to make a careful check.

Thanks,
Marcus