Sebastien Roy wrote: > On Fri, 2009-09-25 at 11:25 -0400, Anurag S. Maskey wrote: > >>> Stepping back a bit, I think our big concern >>> is ending up in the wrong state - we're processing >>> event A, and as a consequence move into >>> state X, but meanwhile sitting in the event >>> queue is a state change event moving us >>> into state Y. Have I got this right? >>> >> Yep, that's exactly right. Furthermore, state X may not be reachable >> from state Y, which I think is the main problem. >> > > I pointed out these issues during the code-review (see seb-051, seb-052, > seb-055, and seb-056). I don't believe that placing events that are > dependent on object state on the event queue works given that events > pending in the queue may modify the state. This means that at a > minimum, there are no reliable error semantics associated with such > events, and in addition, this leads to unexplainable transient errors > that the user can't understand nor control that are caused by kinks in > the implementation. > > Yep, I've been working on door_if.c at the moment and noticed you'd picked up on this - thanks! (I'm hoping to have responses to the door_if.c review comments ASAP). > I don't think that this is hard to fix, however. Can't most door calls > simply be handled in-line? > > We've actually addressed the door_if.c issues as you suggested in the review - the idea is we unconditionally enqueue the disable/enable requests, and the return value sent to the door caller represents the success or failure to request an enable/disable action. This is more consistent with SMF error semantics. Thanks!
Alan
