On Fri, Jun 05, 2009 at 03:17:00PM -0400, Alex wrote:
> Hey there. When working with bufferevents, in what order does libevent
> execute callbacks? Does it fill all the buffers first and then call the
> CBs, or does it fill a buffer and call its corresponding CB, one at a
> time?
>
> From what I understand, it is more efficient to recv and send on all
> available sockets all at once rather than recv, process, recv,
> process, etc.
By default, the bufferevent tries to read as much data as it can, and
it invoke the read callback after it has done so. You can change this
behavior in a few ways, including:
- If you set a low-watermark for reading on that bufferevent, it
doesn't invoke the callback until a given number of bytes are
available.
- If you set the bufferevent's DEFER_CALLBACKS flag, it doesn't
invoke any of the bufferevent's callbacks until it is done
handling IO for all the other active bufferevents. (So if you set
the flag on all your bufferevents, it does IO on all of them, then
it runs all the appropriate callbacks.)
The second feature is only available in Libevent 2. I hadn't heard
about a performance boost from clustering the reads on _unrelated_
sockets, but apparently today is a good day for me learning new
things.
> In my case I have to wait until n bytes are recv'd before I can begin
> processing. Therefore it might not be worth it to use bufferevents,
> since I will have to use buffers which are not drained.
It sounds like you want to look at the watermark feature on
bufferevents. You can set a read low-water mark on a bufferevent, and
you won't get a callback until at least that number of bytes have been
read.
Shameless plug: I'm still making progress in trying to document all
this stuff! You can see the latest draft at
http://www.wangafu.net/~nickm/libevent-book/
It now covers bufferevents. Please send me corrections where it's
wrong.
yrs,
--
Nick
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
