Re: thread ids, task ids and subsystems

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> So, although this definitely introduces quite hurdish concepts into the task
> server, I don't really see a way out, unless you want to route *all* task
> manipulating calls through proc itself (something you didn't want to :).

You're thinking about things like the protocols for transfer of port
rights? I'd expect that every server have to implement that, except
servers that have *only* privileged calls. Or provides its own
protocols for transfer (like the memory server?).

> Also, the task server will be special in that it provides one thread for
> each processor.  But you don't want as many ports representing the same
> task (one port per processor).  So I think that there should be special
> wrapper code that automatically calculates the "port number" (really: the
> thread id of the receiver in the task server) by adding the processor number
> (starting at 0) to the thread number in the thread id of the task "port"
> (which is really just the base thread id in the task server together with
> the number representing the task - favorably simply the pid).

Special casing seems a little ugly. Have I missed something if I
believe that this matters mostly for the calls for creating and
killing threads? Then I'd suggest that only the thread calls be
special cased; use one thread for each cpu that handles thread
creation, and single thread for other task-related calls.

(Either this, or the other extreme, let *every* hurdish port anywhere
in the system have one receiving thread per cpu).

> I have wrapped my mind an hour or so around solutions that try to avoid such
> a sophisticated access control system in the task server itself, and just
> exploit the accounting ID grouping and other things, except that they just
> don't work and don't offer the criteria we need.

I'd love to help (or be educated as to why accounting id:s don't work
;-). One way to avoid the problem might be to say that a task can call
the task server to manipulate itself (and perhaps tasks with matching
account id) directly, but enybody else have to go via proc. Then you
lose the property that a task can give away access to it's task port
to any other task, I'm not sure what the impact of that restriction
is.

One can think of the task server as a server that implements the mach
task features we need + the features that Mach lack and which we
currently need to work-around. In particular, I think the background
for the accounting id idea is an erlier discussion about the tasklist
entry

  * Mach needs a facility to find out what task is the parent of
  a given task.

IIRC, Thomas said that what's really needed is some magic value that
is inherited at task creation. I think that's the simplest thing that
can be robust if tasks are created and destroyed rapidly, and we don't
invent task zombies. I've been calling that magic value "accounting
id" here, earlier I've referred to it as the "owner" of the task.
(There are some other relevant entries in the Mach section of the
tasklist).

Regards,
/Niels