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

[Scott Lamb <slamb@xxxxxxxxx>]

On Thu, Sep 8, 2011 at 9:58 AM, Nicholas Marriott
<nicholas.marriott@xxxxxxxxx> 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.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.
>



-- 
Scott Lamb <http://www.slamb.org/>
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.