[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