Re: new exec server protocol

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> In other words, if you want to write any task server just for the thrill and
> learning effect, that's fine.  If you want to write the Hurd task server,
> then I think it is too early for that.

Well, I want to write something that could evolve to a Hurd task
server, but I don't expect to get the task server precisely right the
first time. If there are questions that can't be answered yet, I'll
just have to make a random decision, and be prepared to change it
later. I also like the task-server to be as simple as possible, and I
tend to think about it as a layer slightly _below_ libports.

> > About thread references, it striked me that perhaps the reference
> > relation is reflexive. I.e. thread A refers to thread B iff thread B
> > refers to thread A. If that's the case, we halve the size of the
> > reference bitmap ;-)
> 
> thread references?  There are no thread references.

Sorry, I meant task references. It was perhaps unnecessary to delve
into implementation details, the interesting observation here is only
that the normal state of affairs (except possibly when handles and
references are in transit), A will have a reference to B if and only
if B has a reference to A.

> > So, how are notifications sent? There should be a call a task can use
> > to get a (randomly selected) death notification. There should also be
> > a separate thread in the task server, that can operate as follows:

[...]

> There is no hard reason to single out one task that gets a big chance to get
> the notification.  Instead, when a task dies, zero time out notifications
> can be send out immediately, no other thread needed.

I guess I got a little carried away ;-) The reason for that hack was
just that if some thread on the task server is going to sleep and
retry retry, it can just as well sleep in an ipc send to one of the
tasks it wants to communicate with.

> So, it might need to retry after a couple of seconds or so.  However, it
> should not retry forever, I guess.  In this special situation, I think it is
> reasonable for the task server to kill a task if it doesn't respond to death
> notification messages for a long time, or if it holds on to task IDs for a
> long time (several seconds or even minutes each).

An unresponsive task consumes some resources in the task server. The
resources will be recovered automatically when that task dies.

I think the current model allows a task to hold references to other
tasks, with out subscribing to notifications. Such tasks should poll
for task deaths occasionally, but perhaps not very often.

Regards,
/Niels