On Fri, 5 Jun 2009 18:15:40 -0400 Nick Mathewson <ni...@freehaven.net> wrote: > > - 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. >
I wanted to use a non-alpha version of libevent, but I just mentally said, "screw it" and decided to use the SVN version. The new features are very nice looking. > > 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. > Hey, great book! I checked it out of git about an hour ago and have been reading it ever since. Since I am decrypting data from the TCP stream I might also want to look in to filtering with the BEV_NEED_MORE flag as well as the aforementioned watermark. -- Alex _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
