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

[Marcus Brinkmann]

At Sat, 05 Mar 2005 15:55:08 +0000,
Matthieu Lemerre <address@hidden> wrote:
> There is some problems though: you cannot do a space_control operation
> if there isn't any thread. So we would have to store the kip and utcb
> parameters, and do the space control when the first thread is
> allocated.
> 
> Space control could also fail during this first thread allocations, so
> we would have to tell the client that "task creation failed", when for
> it, task creation already took place and succeed. I find it more
> confusing.
> 
> (I checked and in fact, we could maybe ensure that space control won't
> fail by carefully checking the kip and utcb arguments in task_create).
> 
> So the implementation wouldn't be easier in fact.

Well, you are right, the KIP and UTCB would have to be stored.  But
that's not too much of a burden I think.

As for failures: Too bad.  Clients who are going to use the task right
away could do a combined task+thread creation call (as I proposed in
my other mail).  As for donated tasks in the suid exec case: There we
have to potentially recreate the address space anyway and deal with
errors.

> Right, I did not express myself clearly. I was meaning that "We have
> to choose one way to set the pager between these three different
> methods", and modifying thread_alloc seems to be the best one.

The pager should be allowed to be l4_nilthread.  In that case, the
pager should be the thread ID of the created thread (essentially
disabling the startup RPC to the pager).  This is not useful for new
tasks, but it is useful for allocation of threads in an existing task.

> >> (And in thread_alloc, if there is nr_threads is 0,
> >> the first thread is activated and the other allocated).
> >
> > What do you mean?
> >
> 
> I meant this: when the client want to allocate the first thread, since
> it is already created (in the scheme I exposed), we only need to
> activate it, only the others are allocated.

Assuming you do pre-allocation of the thread (I'd suggest to just do
lazy creation of the task), you would want to do this transparently to
the user.

> -Where should thread_control/space_control operations happen: in
> task_create or in the hurd_cap_class_alloc function? (This isn't
> needed if we call space_control only after allocating the first
> thread, but even in this case, I'd like to know).

Definitely not in the cap allocation.
 
> -Same for task_terminate: I think that it does not destroy the threads
>  itself, but let task_reinit do it? So it should only drop the
>  reference to the task object?

No, all wrong.  The low level caching mechanisms can't be used here.
All operations should be done in the RPC stubs.

In fact, even the use of the low level cache routines to manage task
and thread IDs is flawed, as unused pages could be purged from the
cache at page pressure (unless we disable that feature explicitely in
the slab, which we can do).

Thanks,
Marcus