On Wed, Jan 29, 2014 at 4:52 PM, Yucong Sun <[email protected]> wrote: > On Wed, Jan 29, 2014 at 12:42 PM, Nick Mathewson <[email protected]> wrote: >> On Sun, Jan 26, 2014 at 2:58 AM, Yucong Sun <[email protected]> wrote: >>> Hi there, >>> >>> So I need to implement a zlib bufferevent filter to transparent >>> compress the data passing through a bufferevent. and but I want the >>> zlib work to be done in a separate thread to offload main loop. >>> >>> I currently call bufferevent_write() on main thread, would the filter >>> code executed immediately? if I call bufferevent_write() from >>> another thread, would the code be executed over that thread instead? >>> (locking is all properly setuped). >> >> The thread in which callbacks happen isn't currently specified by the >> documentation. So it is allowed to change in future versions. >> >> In practice right now, I believe that filters are greedy: they consume >> all input as soon as you give it to them, and they process data from >> the underlying bufferevent as soon as it's read. They do this in the >> same thread where the they receive the data. (This is affected by >> watermarks on the underlying bufferevent.) > > I don't quite understand this, what "callback" were you referring to? > When I call bufferevent_write() on a filtered socket based > bufferevent, would the filters A) get executed recurisvely on the > current thread/stack ? Or would B) it internally add some more events > to the loop and executes the filter code on next callback?
I believe that, in the current code, the filter callbacks (that is, the functions that you provided to implement the filter) get called on the stack. -- Nick *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
