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 (libc/hurdfault.c). 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 implemented). > > 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 glibc) Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
