Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <410A7080D2D2D11185F800A0C9663B823E8954@pulse-bdc.pulse.com> From: Ted Soo-Hoo To: "'cygwin AT sourceware DOT cygnus DOT com'" Subject: Re: 1.1.4 select and poll false positive past 32 descriptors Date: Thu, 10 Aug 2000 15:06:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Chris Faylor wrote: > Thanks for the extra details. I'll fix this. Thanks for taking a look at select. Here are some other comments. I've looked at the source code some more and also tried to learn a little about Win32 programming. I still don't understand all of what's going on in the select.cc code so please do as you like with these. I don't really need an answer. I'll just be pleased if any of this helps. HANDLE w4[MAXIMUM_WAIT_OBJECTS]; This constant is 64 whenever I've seen it. The loop in select.cc is not doing a check for overrunning the array. I hope users who try wide selects won't cause that. I don't quite understand the w4 use. I know that in my test where I set a lot of read bits, m was small. I was also wondering if poll() was implemented with select() as is sometimes done, so had a look at poll.cc. In this file my concern is about width of the fd_set being used. The select.cc code tries to dynamically adapt that by allocfd_set() to the needed bit-width. If poll.cc is using the standard 64-bit fd_set (and FD_ZERO, etc.) it may write past the allocated bits if it gets a descriptor over 63. Still, even if poll has a limit for awhile it would be nice if a really wide select could be supported, as the code seems to try to do. Thanks once again for your help! Regards, Ted -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com