Re: Task server thread and task allocation/deallocation interfaces proposal

[Marcus Brinkmann]

At Thu, 10 Mar 2005 03:21:40 +0000,
Matthieu Lemerre <address@hidden> wrote:
> 
> Marcus Brinkmann <address@hidden> writes:
> 
> > At Thu, 10 Mar 2005 00:04:39 +0000,
> > Matthieu Lemerre <address@hidden> wrote:
> >> I've been thinking a bit more on this, and I can write more clearly
> >> the two proposals of interfaces:
> >
> > Consider the third one, too: Using no group IDs, but just task groups
> > (ie linked lists), no trees.  That seems to be the simplest one to me.
> >
> > I found your description of what a process registration is to be vague
> > and errorneous, but let's not hold ourself up with that, it's
> > something we have to look at in detail later.  (IE, for example, PIDs
> > are always assigned, even to unregistered tasks).
> 
> I must confess that I don't know exactly how capability passing will
> look like.

Not sure what that has to do with it.  The problem with process
registration is a different one.  In fact, I am not sure myself how it
will work out.

In Mach you had the problem that you could create a task and that task
would be totally anonymous.  It would not be associated with any other
task by any sort of group or tree relationship, and it would not be
associated with any user.  As Mach doesn't support any quota
mechanisms, it would also not be accounted for.

However, proc would assign a PID to each individual task, so you could
kill them off if they would go wild on the system resources.

> Moreover, I thought that there would be one PID for one task group (so
> there would have been one PID for several tasks).

Well, that's an idea.  It would be consistent with my idea that you
always kill off the whole task group.  But it may be convenient to
give distinct PIDs, just so that you can get at the information of one
of the tasks within a task group individually without having a
separate interface to name them.

Instead, we could have a separate interface to name the task group.
But the task group could still be named after the PID of one of the
tasks contained in it (a registered task preferably).

> >> This ensure that for every task in a task tree, PROC has a control
> >> capability on its root, and so can destroy it.
> >
> > Proc _always_ will have any arbitrary task capability, just by asking
> > for it.
> >
> 
> OK.  In fact, I was trying to figure out how proc could have a control
> over every task, but I completly forgot that there was already a ihash
> in task server that did the task_id_t => task_t conversion. (Which is
> needed anyway for task info capabilities).

Well, proc will have some sort of "master capability" that allows it
to list all tasks in the system.  Ie, we need a "give me task control
ports for all tasks in the system" RPC that is invoked on this master
capability.  And voila, proc has all tasks.

Instead listing all tasks, there could also be some form of
notification scheme between proc and task for efficiency.  The details
don't really matter that much.  The point is that proc has access to
all task control ports.  Otherwise, how would you implement "kill -9"
for the root user?
 
> Well, thank you very much.  I now understand my mistakes (which means
> that I learned quite much, don't we learn by doing mistakes? :))

Don't assume that I am right.  I have probably spent about the same
amount of thinking on these issues as you, so we are in the same boat.

Process registration is a complex operation, and I am not sure what
the guts of it are.  In Mach, it was also useful/necessary to
associate a process with a certain user.  There were no-user processes
after all.

Well, we can not uphold this, for quota and accounting reasons.  So,
some simple accounting will be done even for unregistered tasks.  But
process registration is also useful/necessary to set various
information about a task and make it a proper POSIX process.

Without laying out details of accounting and quota mechanisms and more
details about fork/exec it is difficult to say more on the subject.

Thanks,
Marcus