[Top][All Lists]

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

Re: emulating no-senders notifications in L4?

From: Marcus Brinkmann
Subject: Re: emulating no-senders notifications in L4?
Date: Thu, 20 Dec 2001 22:52:11 +0100
User-agent: Mutt/1.3.24i

On Thu, Dec 20, 2001 at 09:01:07PM +0100, Jean Wolter wrote:
> > Nice idea. A few potential drawbacks is
> > that
> > 
> > 1. Transfer of port-rights gets more complicated. In particular the
> >    transfer of receive rights becomes more difficult. Does the hurd
> >    ever need transfer of receive rights?
> Sure you would have to contact the owner of the port to transfer a
> send right. How often does this happen? I assume it happens in a fork()
> scenario. And the main question is: Does Hurd actually use the
> possibility to transfer receive rights?

>From a quick search in the code, the signal thread moves its receive right for
exceptions to the proc server.  The proc server forwards those to the tasks,
and diddles the thread state to point to a longjmp instruction 

Also, essential tasks register themselve with init, and pass their exception
port to it.  If there is a message on that port, the system crashes.

The real bummer of course is that a task inserts a new receive right into
the child for each receive right it has when it is fork()ing.

Beside that, there is at least one case where transfering
receive rights becomes interesting.  In the Hurd, we want to use ports in
shell scripts.  A good way to do that is to insert the port rights into the
shell running the script.  I think there are other ways to achieve the same,
but it is really elegant to do it that way.  (This is currently not

> > 2. You get a lot more parties that are interested in task death
> >    events. The task server to keep track of all subscriptions. 
> How many servers are there? How often are tasks created and destroyed
> compared to the number of ipc which would have to go through the port
> server?

I am not sure.  Depending on how you look at it, probably all tasks can be
called a server.  But you can certainly look a bit closer at it and see
where correct dead name and no sender stuff is a requirement.

(the important issues for "normal tasks" are signals/select/fork/faults in


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

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