At Sat, 22 Apr 2006 14:07:00 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > On Sat, 2006-04-22 at 19:24 +0200, Marcus Brinkmann wrote: > > > At Sat, 22 Apr 2006 10:22:25 -0400, > > "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > > 1. The behavior that you want can *only* be accomplished with reference > > > counting. > > > > This is not true. A send-once capability does not require reference > > counting as only ever one reference is extant (guaranteed by move vs > > copy semantics). > > We have a miscommunication. I was referring here to the proposal that > multiple reply capabilities should be permitted to exist, but a notify > would be sent on the last overwrite.
It's always difficult if too many variations of one idea are discussed at the same time. The only option I considered seriously is the "send-once" semantics, because this does not require reference counting and, given the requirements I imposed on the solution (good or bad), seemed to do the job with minimum overhead. If multiple copies of a reply capability are allowed to exist, then one can avoid reference counting by sending a "death notice" on _every_ capability drop, just as the solution you proposed would send a "death notice" on _every_ capability destroy (not only on the last destroy). This is the variation I had in mind when discussing it. These are the only two options I spend any time thinking about. The variation "send death notice on last drop while allowing multiple capability copies" I rejected immediately because of the need to do reference counting. Neither of these two options requires dynamic allocation of kernel storage. In fact, neither of them requires any kernel storage beyond that what is already planned for. > > However, my suspicion is > > that without any such mechanisms, no useful, persistent, fault > > tolerant, user-extensible multi-server system can be built (for some > > definition of useful, which includes running a browser and sharing > > files with friends). > > Fascinating, since there is a known counterexample that was used in > production without a problem for a very long time. Also, note that > AS/400 doesn't have this either! I don't know these systems well enough to decide if they fit my idea of "user extensible" and "useful". It's worth checking out if they faced similar challenges and if yes, how they addressed them. > > > 3. Your proposal seems to have the side effect (I am not certain) of > > > dictating a hierarchical calling relationship. This is bad. > > > > I am not sure what that is supposed to mean. > > I am concerned that move-only capabilities will tend to encourage a > structure in which out of order reply is difficult. I haven't thought > about it, so please do not take this concern too seriously at this > point. Ok. As I said in an earlier mail, I don't know about any other use case involving more than one process getting the reply capability except for forwarding. I'd like to know some. I plan to also check out kernel models which use "thread migration"-like invocation mechanisms. In these systems there also must be some provision to get back your thread eventually. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
