[Openais] corosync trunk - fix null dispatch handlers

Christine Caulfield ccaulfie at redhat.com
Tue Apr 6 00:48:09 PDT 2010


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


More information about the Openais mailing list