Jean Wolter <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Niels Möller) writes: > > > When thinking some more, I realize that you can perhaps distribute the > > "central" registry, giving the owner of each receive right the > > reponsibility to keep track of all corresponding the send rights. Is > > that what you're thinking of? > > Thats right, that was what Michael and Sven implemented when they did > a Mach emulation for L3 (the precursor of L4). Michael mentioned it > some weeks ago and there is a paper on our web sites about it > (http://os.inf.tu-dresden.de/~hohmuth/dir/pub).
Thanks for explaining this. I guess I should read that paper. > > 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? Hmm, I guess most cases port rights that are passed on to other tasks are newly created ones (happens at open(), for instance, and ports handed out by the auth server). > And the main question is: Does Hurd actually use the possibility to > transfer receive rights? I'd like to know that too. > > 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? Probably not more than manageble. > > So far, I've been thinking of delegation (i.e. transfer of send > > rights) as something that is under complete control of whoever wants > > to give a way a right, [...] > Is that information hiding a requirement or just nice to have? If it > is required you need the port server, if not... It is somewhat subtle change, but I don't think it is terribly important. Regards, /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
