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

2011-09-08 Thread William Ahern
On Thu, Sep 08, 2011 at 04:44:26PM +0100, Nicholas Marriott wrote: > 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, n

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

2011-09-08 Thread Bernd Schoeller
On 9/8/11 5:40 PM, Scott Lamb wrote: 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 ow

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

2011-09-08 Thread William Ahern
On Thu, Sep 08, 2011 at 09:40:02AM -0700, Scott Lamb wrote: > 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

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

2011-09-08 Thread Nicholas Marriott
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

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

2011-09-08 Thread Scott Lamb
On Thu, Sep 8, 2011 at 9:16 AM, Nicholas Marriott 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 thin

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

2011-09-08 Thread Nicholas Marriott
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,

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

2011-09-08 Thread Mark Ellzey
> 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 i

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

2011-09-08 Thread Nicholas Marriott
It is however true to say that files will always return as readable and writable but that still means kqueue and poll and hence libevent works :-). On Thu, Sep 08, 2011 at 04:44:26PM +0100, Nicholas Marriott wrote: > On Thu, Sep 08, 2011 at 01:17:22AM -0700, Scott Lamb wrote: > > On Tue, Sep 6, 2

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

2011-09-08 Thread Nicholas Marriott
On Thu, Sep 08, 2011 at 01:17:22AM -0700, Scott Lamb wrote: > On Tue, Sep 6, 2011 at 3:25 AM, Nicholas Marriott > wrote: > > OpenBSD is libevent 1.4.13. > > > > OS X polling mechanisms are pretty bad: their poll() and kqueue() only > > support sockets, so you will need to use select (set EVENT_NOP

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

2011-09-08 Thread Scott Lamb
On Tue, Sep 6, 2011 at 3:25 AM, Nicholas Marriott wrote: > OpenBSD is libevent 1.4.13. > > OS X polling mechanisms are pretty bad: their poll() and kqueue() only > support sockets, so you will need to use select (set EVENT_NOPOLL=1 > EVENT_NOKQUEUE= in the environment). This isn't really limited