Re: task server

[Bas Wijnen]

Marcus Brinkmann wrote:
> At Mon, 9 Aug 2004 22:34:34 +0200,
> Bas Wijnen <address@hidden> wrote:
> >  4. It currently uses static tables of threads and tasks, limiting them to
> >     arbitrary sizes.  This is not acceptable for a final version.
>
>
> In fact, I am afraid to tell you that most of the work is in the data
> structures for efficient operation. ;) But it's good in any case to
> become familiar with how to write servers.

Actually, that was the initial reason to write it.  I expected your task 
server to be finished long before mine, and to be better as well :-)

> > The tables of threads and tasks are used for most operations.  In any case
> > where a task info capability is present, the capability object will point to the
> > task's memory, making it irrelevant how it is stored (in terms of speed.)
>
> You are "misunderestimating" (sorry for the pun) libhurd-cap-server.
<snip>

Unless the thread info of a task is in a static array in the capability 
object, there must be some other table with the info present.  I don't 
think it needs explanation that a static array is not a good idea.  So 
the info is stored somewhere, and there is a pointer to it in the 
capability object.

Anyway, my point was that the lookup of thread info (for creating or 
destroying threads, for example) does not involve searching through a 
list, so compared to getting a task info capability (which does involve 
such a search) it is very fast.

> How to organize the _relationship_ between task caps, task info caps
> and thread allocation is an open question even to me.  It's something
> I want to ponder next, and it is somewhat crucial.  However, for the
> actual cap objects, you don't need to do much.  It's all automagic.

My implementation proposes an answer to the question, of course: there 
are two classes of capabilities from task: info and control.
Control has a power value, which can be 0, 1, or 2.  Higher means more 
power :-)
The power 0 object is the root capability object, so everyone can get a 
capability for it.  It can:
- kill threads in the calling task
- exit the calling task
- get a task info capability for any task
The power 1 object can additionally:
- create threads in the calling task
- create new tasks
The power 2 object can do all that and:
- give a capability to the power 1 object
- kill other tasks

The power 2 object is returned to wortel at boot, to do something useful 
with it.

Task info capabilities have no RPCs at all, but I think they might be 
used to give the preferred thread to use for IPC to the task.

> > The
> > only operation where the task info capability is not present, is "get the task
> > info capability."  This operation is used a lot, so it should be fast.
>
> Well, maybe.  A general side-note: No single RPC must be used a lot.
> If you use an RPC a lot, you are doing something fundamentally wrong
> (I learned this when writing the Hurd console, where I used RPCs to
> send the console data - it was quite slow).  Of course, certain
> operations must still be fast, but usually for different reasons, for
> example to avoid latency with concurrent operations.
<snip>

It's all relative, of course.  Perhaps getting a task info cap isn't 
called that much, but it's probably the one that's used the most (the 
others all being about thread creation and destruction.)  Also, it will 
be the slowest, for it is the only one which has to do a search through 
a data structure.  This can all be quite fast using a hash map or 
something, but I didn't think of that yet.

> In fact, thinking about it, maybe the whole concept of task info
> capabilities is wrong.  Maybe it should just be a single object, and
> you can use RPCs to mark and unmark certain task IDs you are
> interested in watching for task death.  This would be a much more
> efficient implementation.  In fact, this makes a lot of sense to me.
> "Requesting task info cap" was for me always a place-filler for the
> notion of somehow starting to declare your intent to watch out for a
> certain task ID, and avoid that it is reused until you undeclare your
> intent (and get somehow informed about task deaths).

That makes sense, I also had no RPCs at all for them.  However, I just 
thought of one :-)  But that (getting the preferred IPC thread) can also 
be the second return value of the "I want to know when the task dies"-RPC.

Thanks,
Bas

signature.asc
Description: OpenPGP digital signature