Re: [Libevent-users] Different behavior of my code

[Nicholas Marriott <nicholas.marriott@xxxxxxxxx>]

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.

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.marriott@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
> >> unsubscribe libevent-users ? ?in the body.
> > ***********************************************************************
> > To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
> > unsubscribe libevent-users ? ?in the body.
> >
> 
> 
> 
> -- 
> Scott Lamb <http://www.slamb.org/>
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.