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

[Neal H. Walfield]

> I wrote some new RPC for the task server to implement task and thread
> allocation and deletion.

Thanks.

> For basic operations we need the following operations:
> 
> ***task_create(hurd_cap_handle_t current_task_handle,
>              hurd_cap_handle_t *new_task_handle)
> 
> This create a new task, with just one thread, and creates an handle
> associated with it so you can act on the task.

The first argument should be a task server root capability found in
the hurd_startup_data.  As an alternative, we could use
file_name_lookup ("/server/task").  This latter approach means that a
task finds the task server based on its environment.  Having only this
makes it difficult to force a child to use a different task server:
the parent would have to create an entire chroot-like environment.
This is inconvenient.  As I see no added flexibility, I think that the
creator task should pass the task server to the childin the
hurd_startup_data.

Second, allocating a task should not allocate a thread.  Those are
separate operations there is no need to artificially merge them at
this level.  This is easy enough to do at the POSIX level.

> Task creation requires the following steps:
> -creating a new inactive thread
> -calling space_control on it
> -Activating the thread, that is to say setting a pager for this thread.
> 
> Setting the pager can be done:
> -By a separate RPC, task_set_pager(hurd_cap_handle_t task_handle,
>                                    l4_thread_id_t pager,
>                                    l4_thread_id_t thread).

This isn't needed if we set the pager when creating the thread.  Then
it automatically starts waiting for a message from the pager.

> ***task_terminate(hurd_cap_handle_t task_handle)
> 
> This RPC sends task death notification to each task which hold a task
> info capability, and destroy all threads in the task, thus destroying
> the address space.
> It also record somewhere that the task_id is not used anymore.

That looks fine.

> *** task_thread_alloc(hurd_cap_handle_t task_handle,
>                       l4_thread_id_t pager,
>                       l4_word_t number_requested,
>                       l4_word_t all_or_nothing,
>                       l4_word_t *number_allocated,
>                       l4_thread_id_t *thread_ids)
> 
> Neal wanted to alloc several threads at one time, so:
> 
> This allocates NUMBER threads, or less if the server cannot or does
> not want (unless all_or_nothing is set, in which case no thread is
> allocated). Every created thread has its pager set to PAGER.

This looks good.  But rename all_or_nothing to flags and create a
macro called TASK_THREAD_ALLOW_PARTIAL.  This way, we can add more
flags later.

> *** task_thread_dealloc(hurd_cap_handle_t task_handle,
>                         l4_word_t number,
>                         l4_thread_id_t *thread_ids)
> 
> This destroy the threads and put the thread ids back in the free
> thread ids list.

Good.  But you need to know how many were successfully deallocated.
If I pass 3 tids and the second is bad (but the first and third are
valid) then only the first should be deallocated and an error, such as
EINVAL, should be returned and the number of deallocations set to 1.

> When there is only one thread left, the thread is not destroyed but
> just inactivated.

This is an interesting case.  I think it might be better to just
implicitly deallocate the address space.

> (And in thread_alloc, if there is nr_threads is 0,
> the first thread is activated and the other allocated).

What do you mean?


> *On the implementation side, I suppose that we should use the
> task_alloc, ... functions used in the cap_class.

Yes.

> So we should rename the task_alloc function currently written in
> task_alloc_bootstrap or something like that.

I am not clear about what you want to do here.

> *Here is already some patches which are independant of the interface,
> but needed for the task server:
> 
> -This one implements wortel_space_control in wortel:
> 
> [2 wortel.c.patch <text/x-patch (7bit)>]
> 2005-03-04  Matthieu Lemerre <address@hidden>
> 
>       * wortel.c (serve_bootstrap_requests): Implement reply to
>       WORTEL_MSG_SPACE_CONTROL.
>       
> --- mainline/hurd-l4/wortel/wortel.c  2005-02-14 01:22:16.000000000 +0000
> +++ hurd-l4/wortel/wortel.c   2005-02-27 22:54:37.000000000 +0000
> @@ -1231,6 +1231,27 @@ serve_bootstrap_requests (void)
>         l4_msg_load (msg);
>         l4_reply (from);
>       }
> +      else if (label == WORTEL_MSG_SPACE_CONTROL)
> +     {
> +       if (l4_untyped_words (tag) != 5 || l4_typed_words (tag) != 0)
> +         panic ("Invalid format of thread control msg");

I think you want to change the error message.

The rest of this patch looks fine as do the other 2 patches.  Marcus
can check them in if he is happy with them.


Thanks,
Neal