memcache(3) 1.2.0 released...

[Sean Chittenden]

> I'd also like to see all errx() calls removed and handled more
> gracefully, for my use I've updated all of these to just err() and then
> call mcm_server_deactivate() right after and return an error code.

Yeah, they're a rather sore spot for me too.

> It's unacceptable for a memcache error to cause my entire application 
> to
> exit unexpectedly.  No error could be serious enough for this as the
> application can still function 100% (albeit with a big performance hit)
> without the cache working at all.

Yup.  I want to do what I've done with the memory context functions, 
except for with error/warnings.  The goal being that if they're null, 
it's a no-op, whereas if they're non-null, they'll fire off with your 
custom error handling routines.  For now, I'd just delete the offending 
lines (not the answer I want to give, but i need to spend a tad more 
time on this to do it right than I have, nevermind it'd take an ABI 
change, which I'm going to hold off on doing until 1.3.0).

> I'm guessing you are probably in agreement, and just haven't gotten
> around to adding better handling for these conditions yet?

Complete agreement.  warn()/err() are handy when developing something, 
but don't belong in a library.  I can see calling abort() on egregious 
failures inside of the library, but not for normal use cases.  -sc

-- 
Sean Chittenden