Re: task info cap access

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> we talked at the weekend about task info capabilities (formerly known as
> task ID references, or task ID handles).

Perhaps it is a mistake to think about these things as capabilities,
instead of merely references. They also play the additional role as
subscriptions for death notifications; that seems convenient, but
peraps picture gets cleaner if you think of subscriptions and
references as different things. A reference is basically a way to tell
the task server that you're interested in a particular task, and then
the task server promises to keep the owner of the reference up to
date.

I think the protocol for transferring task reference makes sense, it's
simply a protocol that lets a task A point task B to a third point C,
and a way that is robust (i.e. at least fails in a sane way) if any of
A, B or C dies during the process.

The protocol isn't terribly useful by itself, but it is useful as a
building block for other protocols, in particular the general
capability transfer protocol.

> Allowing anybody to acquire any task info caps they want is faster and less
> complex, IMHO.

I don't think it matters very much if you alove any task to ask for a
reference to any other living task. It's a little more estethic if you
don't do that. No matter how you resolve that question, you need some
kind of task reference handshake in the capability transfer protocol,
and an expliciti protocol for reference transfer seems like a nice way
of doing that.

If you can do it significantly more efficient with a specialized
four-party protocol (the four parties are the tasks sending and
receiving a capability, the server for that capability, and the task
server), ok, but it seems like it can get pretty hairy. The
specification for task-server-side of that protocol will be an
important part of the task-server interface and implementation.

Ah, and one more thing,

> My main argument that there is no incentive for a task to keep task
> info capabilities private, and thus there is no need to protect
> them.

I don't think that makes sense as a criterion for what should be a
capability. The same applies for example to read-capability on
world-readable files (and several either file access capabilities, byt
I think the world-readable case is the most obvious one), but I don't
want special non-capability-protocols to handle those.

Regards,
/Niels