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

[Nicholas Marriott <nicholas.marriott@xxxxxxxxx>]

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.


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.