kqueue, poll and file descriptor types
Joel Reymont
"Neither kqueue() nor poll() can handle all types of file-descriptors on MacOSX. The runtime system needs to be able to handle any type of file-descriptor that may appear. We are therefore forced to fall back on select() when a file-descriptor that cannot be handled by kqueue() appears."
Thanks, Joel
--------------------------------------------------------------------------
- for hire: mac osx device driver ninja, kernel extensions and usb drivers
---------------------+------------+---------------------------------------
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
---------------------+------------+---------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (Darwi...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/darwin-dev-garchive-73044%40googlegroups.com
This email sent to darwin-dev-g...@googlegroups.com
Joel Reymont
On Oct 24, 2011, at 4:43 PM, AM wrote:
> Perhaps the above statement was valid once and is needed for legacy compatibility? At the very least the above assertion could be backed up with a counter-example.
What about the BUGS sections of kqueue:
Not all filesystem types support kqueue-style notifications. And even some that do, like some
remote filesystems, may only support a subset of the notification semantics described here.
and poll:
The poll() system call currently does not support devices.
Joel Reymont
On Oct 24, 2011, at 5:01 PM, AM wrote:
>
>> What about the BUGS sections of kqueue:
>>
>> Not all filesystem types support kqueue-style notifications. And even some that do, like some
>> remote filesystems, may only support a subset of the notification semantics described here.
>
> That refers to vnode-watching which select() doesn't support anyway, so that's not it.
Fair.
>>
>> and poll:
>>
>> The poll() system call currently does not support devices.
>
> As far as I am aware, select() and poll() are strict subsets feature-wise of kqueue, so I would be very curious to find a counter example.
So what about devices in BUGS for poll?
Shantonu Sen
In practice, the main complaint has traditionally been the lack of kqueue support for TTYs, which was resolved in Lion.
Shantonu Sen
ss...@apple.com
> http://lists.apple.com/mailman/options/darwin-dev/ssen%40apple.com
>
> This email sent to ss...@apple.com
Joel Reymont
On Oct 24, 2011, at 5:32 PM, Shantonu Sen wrote:
> In the abstract, the statement is true (is this a homework question or something?)
There's a chunk of code in the Erlang virtual machine that clips the maximum number of file descriptors to FD_SETSIZE, 1024 by default, at compile time.
It only does this on the Mac, claiming the need to fall back to select when kqueue fails.
--------------------------------------------------------------------------
- for hire: mac osx device driver ninja, kernel extensions and usb drivers
---------------------+------------+---------------------------------------
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
---------------------+------------+---------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (Darwi...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
Tilghman Lesher
>
> On Oct 24, 2011, at 5:32 PM, Shantonu Sen wrote:
>
>> In the abstract, the statement is true (is this a homework question or something?)
>
> There's a chunk of code in the Erlang virtual machine that clips the maximum number of file descriptors to FD_SETSIZE, 1024 by default, at compile time.
>
> It only does this on the Mac, claiming the need to fall back to select when kqueue fails.
While that's true in the default case, one needs only to define
_DARWIN_UNLIMITED_SELECT at compile time (before system headers are
#include'd). You still would need to expand the fd_set to a larger
bitfield, should you use that construct. We've done this in the
Asterisk project, for example.