On Thu, Sep 8, 2011 at 9:58 AM, Nicholas Marriott <nicholas.marri...@gmail.com> wrote: > Well, yes. But there are good reasons to use libevent as well as not > blocking. Code design jumps to mind, and the added value stuff like > bufferevents. > > If blocking doesn't really matter, it's useful to be able to treat file > descriptors the same no matter what they point at. Special casing > different types of file descriptors is a mess. > > In my case I mostly have fds that came from stdout/stdin/stderr (so > could be anything) or from ptys. I need some way of multiplexing them > and libevent is way simpler than threads. So the only choice on OS X is > to drop back to select.
I see your point, fwiw. I just wish it were possible to do much better than that, but I don't think it is given the available OS interfaces. One could imagine a bufferevent implementation that used aio, though I'm not sure what OSs have a satisfactory aio implementation... > > Anyway, I agree that if you are working on files alone then libevent is > unnecessary. If you just want to play either use sockets or avoid OS X > or force it to use select ;-). > > > On Thu, Sep 08, 2011 at 09:40:02AM -0700, Scott Lamb wrote: >> On Thu, Sep 8, 2011 at 9:16 AM, Nicholas Marriott >> <nicholas.marri...@gmail.com> wrote: >> > Yes you can't rely on file operations being nonblocking but in many >> > cases that doesn't matter - the real problem is that if you can't manage >> > file descriptors that point to real files with libevent it isn't >> > possible to use it for things such as stdout which the user can easily >> > change between a tty, a pipe, a file or a special device such as >> > /dev/null. >> > >> > So whether or not the file descriptor is actually nonblocking, support >> > for poll/kqueue is useful, even if it just always returns readable and >> > writable. >> >> It sounds like we're agreed on the facts but not the more subjective >> evaluation of what is useful. As far as I'm concerned, the point of >> using libevent is to never block. If you don't need that, you can just >> assume the file descriptor is always available rather than waiting for >> events on it. I suppose that if you need to assume regular files are >> always available but not these other types (which seems odd, imho), >> you can use fstat() to determine the type of file and wait for events >> on it or not. >> >> Going back to Bernd Schoeller's original question: if "in.dat" and >> "out.dat" are regular files, there's nothing useful libevent can do in >> this program. If you just want to try out libevent, I'd suggest >> playing with sockets instead. If you want to write your own cp that >> overlaps reads and writes, I'd suggest (1) using threads, (2) aio, or >> (3) mmap()ing the source file and doing a write() directly from this >> memory to the destination. (The mmap() only works if your platform's >> virtual memory size is sufficient for the file in question. I'd avoid >> it on 32-bit platforms.) >> >> > >> > >> > On Thu, Sep 08, 2011 at 11:03:27AM -0500, Mark Ellzey wrote: >> >> > Nonblocking I/O has not much to do with it, you don't necessarily need >> >> > nonblocking I/O if you have working poll(2) or select(2). >> >> > >> >> > It is a limitation of OS X. Every other platform with kqueue(2) and all >> >> > I am aware of with poll(2) support it on all file descriptors. OS X >> >> > doesn't support it on anything other than sockets - so not on ttys, not >> >> > on files, not anything except sockets. >> >> > >> >> > This is annoying because it means you can't manage tty file descriptors >> >> > or file descriptors linked to devices such as /dev/null (both of which >> >> > are commonly used for eg stdout) with libevent unless you force it to >> >> > use select. >> >> > >> >> >> >> Correct me if I'm wrong here, but while you can technically have a file >> >> descriptor set to non-blocking, you are still limited to flush >> >> operations which result in CPU waits. This can result in blocking. >> >> >> >> *********************************************************************** >> >> To unsubscribe, send an e-mail to majord...@freehaven.net with >> >> unsubscribe libevent-users ? ?in the body. >> > *********************************************************************** >> > To unsubscribe, send an e-mail to majord...@freehaven.net with >> > unsubscribe libevent-users ? ?in the body. >> > >> >> >> >> -- >> Scott Lamb <http://www.slamb.org/> >> *********************************************************************** >> To unsubscribe, send an e-mail to majord...@freehaven.net with >> unsubscribe libevent-users in the body. > *********************************************************************** > To unsubscribe, send an e-mail to majord...@freehaven.net with > unsubscribe libevent-users in the body. > -- Scott Lamb <http://www.slamb.org/> *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
