On 02/04/10 17:19, Steven Dake wrote: > On Fri, 2010-04-02 at 09:31 +0200, Jan Friesse wrote: >> Steve, >> this one will change behavior for (dispatch_types == CS_DISPATCH_ONE). >> Original behavior: >> - Message received >> - Callback is not registered -> continue AND WAIT for another message >> - Loop until at least one callback is called >> >> New behavior: >> - Message received >> - Callback is not registered -> break and stop loop -> return to app, >> but without ANY action. >> >> Question is, what behavior is correct, more logic? From my point of >> view, original one. >> > > Well original implementation led to deadlock, of the dispatch routine, > but a patch that tracks actual dispatches and uses that as the basis for > determining if DISPATCH_ONE should continue would be helpful :-) > > The model of DISPATCH_ONE is it should dispatch a callback if one is > available, but if none are available, it shouldn't block.... In the > case of a null callback, it should probably try to dispatch atleast one > callback, but not block in the process. >
I agree with Steve and like the new model. The way I use CS_DISPATCH_ONE is after an fd becomes active from select(). As far as the outer loop is concerned it doesn't care whether a callback was run or not - only that the even has been consumed so it can go back to select(). Chrissie _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
