On Thu, Jun 15, 2006 at 09:58:40AM +0200, Corinna Vinschen wrote: > > thread + select(). One thing I notice is that if a read() is in progress > > and one > > is currently sitting in select(), all other read()s in seperate select()s > > will > > then stall if the former read() times out or takes longer than expected. > > Your observation is correct, the same issue exists for recv/send and, > FWIW, connect. I can fix the connect case, too, but there is no easy > patch for the recv/send case, unfortunately. This has to do with the > way WSAEventSelect is handled in WinSock. > > For now, if you want concurrency, either use non-blocking recv/send > exclusively, or never spread handling of the same blocking socket over > multiple threads. Hopefully I can come up with a solution for this > problem at one point. > > Corinna
Actually the behaviour I'm noticing is within the same calling thread. For instance, in almost all of my network functions I'm passing an fd and using that fd with select to handle timeouts (connect/read/write all NB). So in each case the same calling thread is doing the typical sequence: socket -> connect -> write -> read -> close. The fd returned by socket() is never used outside of that thread. So instead of a single thread w/ a single select and iterating over multiple fds, post-select(), I have a thread pool with only one fd-used-at-once-per-thread but multiple threads executing concurrently. When a seperate fd entirely exhibits a read() timeout, it appears to affect read/write in all other threads using different fds. Basically, as long as data is flowing in all threads, there is no issue - but the second any one fd stalls in any given thread - they all stall until I close that fd after read() times out (where select() is indicating the timeout). You can see the implementation of these network functions in the original test case. I basically have a thread pool with each thread calling those functions in the same order socket, connect, write, read, close. -cl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
