Jean Wolter <[EMAIL PROTECTED]> writes: > If I understand your "reasoning" right you need the extra level of > indirection to implement a reliable "no sender notification" for the > case, that > > - a task does suicide > - a task dies violently (with this I assume you mean it raises > an exception and is killed by the micro kernel).
Right. > As Volkmar already pointed out it is impossible for a task to do > suicide since only the task server is allowed to create and delete > tasks. > > And a task can not die violently since if it raises an exception this > exception is delivered to an exception handler thread which can handle > this situation. Is this thread running inside the task in question or in some other task? > So it should be possible to inform all interested servers about the > death of a task and therefore all server could clean up their > resources if the dying task was the last user. AFACS, this is a good way to make reliable task-death noticifications work, but by itself it isn't enough for reliable port-senders notifications unless. At the point when the tasks dies, it's data may be FUBAR, so the only information about the task that is *reliably* available is its id and the fact that it's dead. How do you know what port-rights it had? I'll try to sum up my reasoning, to let you point out where it is wrong. There are two "devil's advicate" scenarios. First, consider a task that owns a few send-rights. Then it (intentionally or accidentaly) overwrites all its information about those rights. And then the task dies (it doesn't really matter how it achieves death). In order for this situation to be cleaned up properly, including the sending of appropriate no-senders notifications, the information about the send rights must be registered by some trusted entity outside of the task. So lets assume we have this trusted send-right registry. Now consider a task that doesn't keep the information up to date; it may receive a send right from somewhere, and not register it. Or it may tell the registry server that it has destroyed the send right, without destroying it. To make this work right, one must ensure that a send right that isn't properly registered cannot be used. Sending all rpc:s through the trusted port-rights server, i.e. adding a level of indirection, is one way to achieve this. Okuji's idea of mapping the table read-only into all tasks is another way, but it can't handle all rpc (in particular, rpc:s that imply a transfer of port-rights, although by my own reasoning it's fine if those rpc take a different and more costly way), so for now I'm thinking about it as an optimization of the rpc indirection. Summary: The central book-keeping entity is indeed necessary. Whether or not all rpc:s should actully be routed *through* that entity is an open question. ... 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? 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? 2. You get a lot more parties that are interested in task death events. The task server to keep track of all subscriptions. A side effect is that the receiver gets the power to unilaterally revoke any send right of its choice. This may be natural, but I'm not sure the receiver has that power in Mach. 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, and that the receiver should not care (or even know) that delegation has taken place. That information hiding is possible with the central port-rights server, but not in the distributed model. Best regards, /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
