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

[Scott Lamb <slamb@xxxxxxxxx>]

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.