memcache(3) 1.2.0 released...
sean at chittenden.org
Thu Jan 20 00:41:28 PST 2005
> 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
> 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
More information about the memcached