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.
