On Thu, Jan 29, 2009 at 10:48:26AM +0100, Trond Norbye wrote: > > Bill Moseley wrote: >> Yes, I can trap the signal, thanks. I guess I'm more wondering what the >> behavior should be. And maybe there's no simple answer. >> >> libmemcached works with sockets so should expect a possible SIGPIPE. >> And the library is somewhat of an abstraction in that from the >> application's point of view it is just storing and fetching and >> doesn't really know how the library does that magic. >> >> I guess my assumption was libmemcached would trap the signal, flag the >> server as down (to stop attempting to use it) and return an error >> stating which server generated the signal. Then someone scrambles to >> replace that downed server. >> >> But, perhaps ignoring the signal is the better approach and use a >> separate process to look for failed memcached servers. >> >> > Personally I don't think the library should install a signal handler, > because you as a developer might want to trap SIGPIPE (maybe not the > ones generated by libmemcached, but others in your program).
Excuse my poor IPC skills, but could the SIGPIPE handler be localized just to the library's socket calls and then restored? I guess there's risk that something else might interrupt before restoring the handler. I'm happy to handle the SIGPIPE in my application, but I assume the library checks for errors on the socket calls so catching SIGPIPE would seem to fit into that same category of error checking. But, perhaps not. -- Bill Moseley [email protected] Sent from my iMutt
