[Openais] Re: thoughts on saClmDispatch() shortcut

[Steven Dake]

On Tue, 2004-06-29 at 11:13, Chris Friesen wrote:
> 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.
> 

Sounds like a much better approach.  Can you make a patch for one of the
services (like AMF) so we can try it out?

Thanks
-steve

> Chris