[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Task destruction

From: Niels Möller
Subject: Re: Task destruction
Date: 05 Aug 2002 23:48:51 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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
  Each task is associated in the task server with a list of handles to
  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

  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]