Re: [Libevent-users] regress application
William Ahern wrote: I'm as much a standards pendant as the next guy, but can you point out any implementation that forks threads (i.e. the fork'd process keeps the threads), or where otherwise forking (other than from a signal handler), actually creates issues? I even expect a positive response, and I think actually pointing them out would be productive. But the vfork() issue Actually the rationale I meant was this: https://sun.systemnews.com/articles/99/5/sw/16419 Sorry about that. Do I need to produce an example? No. The standard says 'don't do it' and that's that, surely? Most code that's threaded will expect the standards to be followed and surely all the gross ugliness necessary to unwind everything with pthread_atfork isn't always there and is unlikely to be bullet-proof. What's the problem? You have the 'run in child' mechanism there for Windows, so use it in POSIX too and its job done, whether or not there are any threads in play. If you *know* you only have one thread then its fair game to do the old thing, but we're talking about a process that has regress_pthread in it. Surely it used to be that as an app developer I was pretty much in control of whether my process was threaded, but now its increasingly hard to write applications where that's the case unless you are prepared to rebuild a lot of support libraries, and its hardly worth the effort any more. What's the point? ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] How libevent works
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
Re: [Libevent-users] regress application
Nick Mathewson wrote: Do you want to write the patch to make the unit tests use the right interface as appropriate? No. I've posted a couple of patches into your patch system. These help but I've not attempted to get to a polished state - just a slightly better one. I think, for example, that the places where you include windows.h should probably be winsock2.h or ws2tcpip.h, so there are detail changes that could be made to tidy things up somewhat, and that's outstanding. My waf build system is running OK on Ubuntu and Vista but I need to test it on Solaris and at least one BSD, so I haven't uploaded it yet. It will provide a wscript and an event-config.h that includes a generated event-config-generated.h. I can't justify spending time on the libevent core, so don't expect much more from me except some testing, (apart from a waf script - I'm interested in exercising waf currently as a learning exercise) for the moment. James ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] How libevent works
On Fri, Jun 05, 2009 at 06:31:35PM -0400, Alex wrote: [...] 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. Okay! You should know that the filtering is a little experimental, and so you might run into bugs or API warts on it. If you can't make it do what you want, don't assume that you are the one at fault: let us know. Also, if you're using SSL/TLS, be aware that you can't actually write a filter for it using the bufferevent_filter API, since sometimes a TLS read operation can require underlying reads _and_ writes, and the bufferevent_filter API only works for filters that work as a pure transform on an input or output stream. yrs, -- Nick ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
