Re: task-server hacking

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> I think you should reread my mail where I describe subsystems.

Ok, I was just going to ask on how to deal with that. If the task
server should be able to serve more than one subsystem.

If it's for one subsystem only, then it can get that subsystem from it's
own thread id, and then it should refuse to respond to messages from
other subsystems. (Bootstrap is still fuzzy, of the bootstrap starts a
few tasks in the hurd subsystem, and one of them is the task server,
then the task server needs to know in what range the thread numbers of
the other tasks lie. Have you thought about that already?

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 ;-)

I've started to think about notifications. I think there should be two
datastructures, one is the refer-to relation, which can be thought of
as a square n times n bitmap, if n is the maximum number of tasks (it
might be implemented differently). There is also a list of pending
notifications, which can also be thought of as a bit matrix (although
it will be even sparser, so more likely to be implemented as a list)

Entry A,B in the reference matrix is set iff the live task A has a
reference to the live-or-zombie task B.

Entry A,B in the pending matrix is set iff the live task A has not yet
been notified of the death of zombie B.

When a task A commits suicide, this is what happens:

  All entries A,x in both the reference matrix and the pending matrix
  are cleared. A clearly is no longer interested in any notifications.

  For each entry x,A in the reference matrix that is set, the entry is
  cleared, and instead the corresponding entry in the pending matrix
  is set.

  If there are any x,A entries in the pending matrix, A turns into a
  zombie. Otherwise, it is deallocated.

When a notification of A:s death is sent to a task x (more on this
below) successfully, the x,A entry in the pending matrix is cleared.
If this is the last entry for A, A is deleted.

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:

Form the list of pending notifications, for which the receiver thread
wants the server to send an rpc (a task can have a reference without
having requested explicit notifications). Send an rpc with zero
timeout to each but one of the receivers. To the final one, send the
message with a pretty large timeout, say one second or so. Which
receiver that gets the large timeout should change for each run over
the list.

Whenever a task dies, so that entries are added to the pending list,
the notification thread should be woken up (don't remember, but the
other thread should interrupt the blocking ipc send).

I haven't thought much about locking yet (there's currently only a
single thread, and no notifications), it's too early to say what lock
granularity is needed, and I think I need some advise to get that right.

/Niels