More mupdate questions.

[Wesley Craig]

On 30 Mar 2009, at 12:41, Dave McMurtrie wrote:
> The fundamental problem is that kick_mupdate() returns void.  If a
> mupdate slave is not currently listening on its local AF_UNIX socket
> (like when it disconnects because it loses contact with the mupdate
> master) kick_mupdate() will attempt to connect, fail, log an error and
> return.  Most of the calling code I looked at assumes that if
> kick_mupdate() returns, the local database is current.  In this case,
> that may or may not be true.  At the very least, I think  
> kick_mupdate()
> needs to be updated to be able to return a status so any calling code
> can make a more informed decision about what to do.

I don't have a big problem with more information being provided to  
the caller, but I'm not all that clear what you'll do with the  
information in most cases.  If the socket was open, you'd block  
waiting for the MUPDATE NOOP to happen.  With the socket closed, what  
are the superior behaviors?

> The area for improvement is that kick_mupdate() never times out its
> read() from mupdate's local unix socket.  Wouldn't it be a good  
> idea to
> wrap this read() in an alarm() call and return failure?

See above.  I'd want to see an analysis of what each of the callers  
would do with the returned kick_mupdate() status.

:wes