This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 1.1.4 select and poll false positive past 32 descriptors


On Tue, Aug 08, 2000 at 05:21:49PM -0400, Ted Soo-Hoo wrote:
>The idea for polling comes from select.cc code which goes down a
>different path for that case.  I also ran under strace and saw that a
>pended operation bases its returned size on a value n which is always
>small, e.g.  1 or 2 and not the expected value to copy out.  That value
>should be based on the maximum file descriptor given by the user, but
>not work too hard beyond that.

From the linux man page on select:
       n is the highest-numbered descriptor in any of  the  three
       sets, plus 1.

What is allocated in select.cc reflects the maxiumum number of fds
that can be operated on.  It's essentially a bit mask.  I don't know
why you are mentioning this.  If your maximum fd is something like
64, then the fd_set's allocated should be at least that large.

I don't know what "the expected value to copy out" might be or what
you mean by "not work too hard beyond that".

>A possible fix would be to change the loop that does the counting to
>count n less conditionally.  Just a thought.  I don't understand all
>the code.

I think what you are reporting is that the winsock version of select
only handles 32 elements.  That's an unfortunate limitation.  It would
probably be possible to work around this by forking multiple threads to
handle multiple winsock selects but this would be a fairly major change
and I am not aware of anyone contemplating this.  Sorry.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]