Rationale: we hold a lock on the bufferevent when its callbacks are
executing, so we need to release the lock afterwards. But the
callback might free the bufferevent, so unless we're holding a
reference on the bufferevent, the lock might not be there for us to
release.
svn:r1347
Paired and asynchronous bufferevents didn't do timeouts, and filtering
bufferevents gave them funny semantics. Now they all should all work
in a way consistent with what socket bufferevents do now: a [read/write]
timeout triggers if [reading/writing] is enabled, and if the timeout is
set, and the right amount of time passes without any data getting
[added to the input buffer/drained from the output buffer].
svn:r1314
OpenSSL uses something like this to implement get/set access for
properties on its BIOs, so that it doesn't need to add a pair of
get/set functions to the vtable struct for every new abstract property
it provides an accessor for.
Doing this lets us make bufferevent_setfd abstract, and implement an
abstract bufferevent_getfd.
svn:r1284
Either I need to make the callbacks get deferred in a base with no events (doable), or I need to make it okay to call launch_read from inside the callback for read (tricky).
svn:r1277
