Re: thread ids, task ids and subsystems

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> The issues as I see them are the following:
> 
> * Do we make use of the port/handle concept in the task server or
> not?

It seems task ports makes life simpler. I'm not sure that the
protocols for dealing with ports (e.g. giving away access to a port)
should be considered as hurd specific, sure, we need them, but they
could be useful for almost any non-monolithic OS built on top of L4.

> * Accounting ids are then free to be just that, and used for accounting. 
>   That means accounting the tasks resources as well as some sort of task
>   relationship.

I think I want a per-process accounting id, assigned by proc. The main
reason is that I want to be able to easily kill a process and all
unregistered tasks it has created. So I'd say that the id:s are
assigned when a task registers with proc (and otherwise inherited). If
we have multiple id:s, I'm sure there are interesting uses of id:s
assigned by other servers at other times.

Accounting at a larger scale, like per uid, per session or per process
group should be done by proc, as it's proc's responsibility to know
about things like process persona, sessions and process groups.

>   This can be made a bit more flexible by splitting the accounting id
>   into a system part and a user part, and let users set the user part
>   freely.

I'd prefer the multiple accounting id thing, but I'm afraid it adds
some more complexity to task.

> * How to get maximum thread creation/destruction performance.  Indeed, we
>   need either a special case here, or we have a processor field in the
>   handle which is set to the processor id.

At the moment, I'm too confused on this issue to suggest anything.

Regards,
/Niels