Eventmachine talk - Jan 2008 - Eventmachine-talk Digest, Vol 21, Issue 19

Yeah at least for mingw you can create 256 descriptors, but only the
first 64 seem to fit in a descriptor set, despite setting FD_SETSIZE.
The same holds true for Unix--if you go out of your way (easy to do if
you''re load testing) then you can create descriptors that
won''t fit in
a set.  See the patch.  I actually wonder if ruby itself even bothers
checking for this--my gut feeling is that they don''t, and that
therefore ''stress testing'' network apps on Ruby (using ruby
threads,
and ruby''s normal select) causes some serious unanticipated problems.
I''ll be sticking with EM for now, thank you :)
-Roger
> It''s possible to accept a socket that''s too high-numbered
to work in a
> select set, if the process is permitted to create a larger number of
> descriptors than FD_SETSIZE. You''re really not likely to see this
on
> Windows, however. (On some versions of Windows, file descriptors are
> pointers rather than index numbers, anyway, so there''s no
meaningful numeric
> comparison.) On Unix you can make it happen if you go out of your way.
>
>
> So you''re making a good point and it''s worth validating
that a descriptor is
> selectable.
>
> I think that our future direction really should be away from select and
> toward the native high-performance polling mechanism on all platforms. We
> have epoll and kqueue now. We should add /dev/poll for Solaris and IOCP for
> Windows. Then the only platforms left on select will be be back versions of
> Linux and less-common Unixes.

The real problem on Windows is that the WaitForMultipleObjects() function
which is the basis of all Win32 event monitoring is limited to 64 objects.

I/O completion ports are the only mechanism Microsoft has provided to
surpass this limit.

On Jan 11, 2008 1:11 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:
> Yeah at least for mingw you can create 256 descriptors, but only the
> first 64 seem to fit in a descriptor set, despite setting FD_SETSIZE.
> The same holds true for Unix--if you go out of your way (easy to do if
> you''re load testing) then you can create descriptors that
won''t fit in
> a set.  See the patch.  I actually wonder if ruby itself even bothers
> checking for this--my gut feeling is that they don''t, and that
> therefore ''stress testing'' network apps on Ruby (using
ruby threads,
> and ruby''s normal select) causes some serious unanticipated
problems.
> I''ll be sticking with EM for now, thank you :)
> -Roger
>
> > It''s possible to accept a socket that''s too
high-numbered to work in a
> > select set, if the process is permitted to create a larger number of
> > descriptors than FD_SETSIZE. You''re really not likely to see
this on
> > Windows, however. (On some versions of Windows, file descriptors are
> > pointers rather than index numbers, anyway, so there''s no
meaningful
> numeric
> > comparison.) On Unix you can make it happen if you go out of your way.
> >
> >
> > So you''re making a good point and it''s worth
validating that a
> descriptor is
> > selectable.
> >
> > I think that our future direction really should be away from select
and
> > toward the native high-performance polling mechanism on all platforms.
> We
> > have epoll and kqueue now. We should add /dev/poll for Solaris and
IOCP
> for
> > Windows. Then the only platforms left on select will be be back
versions
> of
> > Linux and less-common Unixes.
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080111/578b1287/attachment.html