Re: Task destruction

[Niels Möller]

address@hidden (Neal H. Walfield) writes:

> I had started to consider this problem, however, had not gotten very
> far.  This approach does make a lot of sense.  The only open issue
> then is how to determine who the privileged server.  Do you have any
> ideas?  Should this just be some parameter?  The first to register as
> such?  Or perhaps, you had something else in mind.

What about the following outline?

  A handle is a pair <target, id> (Wolfgang's definition), and in our
  context all targets will be proc servers, and the handles identify
  processes.
  
  Each task is associated in the task server with a list of handles to
  processes.
  
  At task creation, the list is inherited (by copy, semantically) from
  creator to creature.

Modification of the list is only allowed as follows:

  If the handle list is empty, anyone can add a handle. This happens
  primarily at initial bootstrap, but in general, anyone can adopt a
  task that is completely orphaned.
  
  When a task is created, the creating task can add a handle with itself
  as the target. This is done by boot.
  
  The the proc-server that is mentioned as the target in a handle is
  allowed to change that particular handle in any way it likes, both
  the target part and the id part. The usual case is that only the id
  part is changed, and that happens whenever a new process is created
  (i.e. when a task is registered with a proc server).

As far as I can see, this avoids the notion of any globally
"privileged" proc process(es).

  At initial bootstrap, all processes are privileged (the empty list
  case).

  Later on, a proc-server is "privileged" for a task if and only if it
  owns some process that owns the task. (More than one proc server may
  be privileged for a given task).

  Furthermore, any task has the oppurtunity of making itself
  privileged for tasks it creates, which seems natural.

/Niels