On Sunday 25 September 2005 07:37, Conrad T. Pino wrote: > > From: Derek Price > > > > Incidentally, if you wanted to provide a replacement select() function > > on Windows, here is how Cygwin did it (from > > http://sources.redhat.com/cygwin/cygwin-ug-net/highlights.html): > > > > > > Select > > > > The UNIX select function is another call that does not map cleanly > > on top of the Win32 API. Much to our dismay, we discovered that the > > Win32 select in Winsock only worked on socket handles. Our > > implementation allows select to function normally when given > > different types of file descriptors (sockets, pipes, handles, and a > > custom /dev/windows Windows messages pseudo-device). > > > > Upon entry into the select function, the first operation is to sort > > the file descriptors into the different types. There are then two > > cases to consider. The simple case is when at least one file > > descriptor is a type that is always known to be ready (such as a > > disk file). In that case, select returns immediately as soon as it > > has polled each of the other types to see if they are ready. The > > more complex case involves waiting for socket or pipe file > > descriptors to be ready. This is accomplished by the main thread > > suspending itself, after starting one thread for each type of file > > descriptor present. Each thread polls the file descriptors of its > > respective type with the appropriate Win32 API call. As soon as a > > thread identifies a ready descriptor, that thread signals the main > > thread to wake up. This case is now the same as the first one since > > we know at least one descriptor is ready. So select returns, after > > polling all of the file descriptors one last time. > > > > > > The POSIX specification for select is here: > > <http://www.opengroup.org/onlinepubs/009695399/functions/select.html>. > > For now, I think it would only need to handle files (Cygwin says files > > are always ready for read on Windows), sockets (Windows select() can be > > used), and pipes (I have no idea how to find out if a pipe is ready for > > read on Windows). > > I'm not so sure disk files are always ready. They may use this approach > because I can't find a way to find out if a disk file will block without > actually launching an asynchronous read/write operation which raises the > problem of what to do with the data when the operation suceeds!!! > > I assume you've seen prior message pointing out "PeekNamedPipe" function. > > The Win32 Native API supports extensive I/O and execution concurrency: > http://msdn.microsoft.com/library/en-us/dllproc/base/synchronization_and_ov >erlapped_input_and_output.asp but everything I reads seems to require the > operations be launched. > > Can you describe the general I/O concurrency strategy CVS uses or wants > to use on POSIX platforms? > > > Of course, figuring out why this behavior changed since 1.12.12 might be > > easier. > > I assume you've seen my prior message about the bad behaviour existing > in version 1.12.12 also. Does it make sense to probe versions earlier > then 1.12.12 to see if we can revert to that method?
The problem already has been visited in February 2005. I have opened a thread on this issue quite a while ago, see here: http://lists.gnu.org/archive/html/bug-cvs/2005-02/msg00014.html Regards Frank _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
