[Openais] thoughts on saClmDispatch() shortcut

Chris Friesen cfriesen at nortelnetworks.com
Tue Jun 29 11:13:46 PDT 2004


Steven Dake wrote:

> You mean add a flag to saClmDispatch?  The downside of that approach is
> that the API then becomes nonstandard for a small performance payoff.
> I'd like to match the AIS standard as much as possible, even when it
> means performance won't be right.  The longer-term approach to this
> problem is to drive that kind of feedback into the specs group which
> I'll do.

I just had a thought on how to get the performance without any API changes.

The first thing that hit me is that you don't actually need poll() in 
saClmDispatch()--you're only monitoring one file descriptor as to whether its 
readable.

Next, saRecvRetry() allows you to pass flags through to the underlying recvmsg() 
call.

The combination of these two things means that we can simplify things greatly.

The algorithm for saClmDispatch() becomes:

For SA_DISPATCH_ONE and SA_DISPATCH_ALL, use MSG_DONTWAIT flag.  We shouldn't be 
using MSG_WAITALL for these anyway, because they are supposed to invoke 
*pending* callbacks, not block waiting for the rest of a message to come in. 
This implies that for correctness we need to return immediately if only part of 
a message has arrived at the time of the call to saClmDispatch().

If the return code of recvmsg() is -1, and errno is EAGAIN, then we know there 
were no messages waiting and should somehow pass this back in the return code of 
saRecvRetry().  saClmDispatch() then just returns SA_OK without doing anything.

If there is a complete message, handle normally.

For SA_DISPATCH_ONE, we then return.

For SA_DISPATCH_ALL, we just jump back to just before the read and do it all 
again--eventually the rx buffer will be empty and we'll get EAGAIN, at which 
point we return as discussed above.

For SA_DISPATCH_BLOCKING, we jump back similarly to SA_DISPATCH_ALL, except that 
since we are using blocking reads, we'll never get EAGAIN.  Thus we just sit in 
an infinite loop.

This gets us the best of all worlds, and I think it might even clean up the code.

Chris



More information about the Openais mailing list