On Wed, Apr 3, 2013 at 4:26 AM, Sebastian Sjöberg <sebastian.sjob...@axis.com> wrote: > Hello, > > Is it possible that evbuffer_add_printf triggers an event callback on a > bufferevent before returning?
Yes. When deferred callbacks aren't enabled on an event, then it's possible that when you queue data, that data can be flushed to the backend immediately, particularly with filtering bufferevents. If that data is written right after you queue it, then a write callback can happen immediately. This is not something I regard as good behavior on Libevent's part; see below. > We've had a system based on libevent running for years and suddenly tuesday > morning it started crashing. Gathering information from core files and logs > we've concluded that the event callback on the SSL bufferevents is called > when we call evbuffer_add_printf. > > After changing to deferred callbacks on the bufferevents the issue is gone. > The biggest question we're asking ourselves is, why did the callbacks > suddenly fire now after years of not firing? That's a hard one. If it's truly sudden change in behavior with no change in libevent or your codebase or your OpenSSL version, I'd look for changes on the other side, or changes in network behavior, or something. Incidentally, I would like to use Libevent 2.1's new smarter callback logic to make it so Libevent 2.1 (or 2.2, or whenever) has a better notion of when to invoke callbacks like that. Instead of having a choice between never delaying the callback (the default), or always delaying the callback (as happens with the deferred flag), I'd like to have a design where the callback is deferred if it would give surprising results to user code, but can get called immediately if it's invoked from within libevent callback. That way we avoid performance penalties *and* surprising results. yrs, -- Nick *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
