Re: Windows CVS 1.12.12.1 Latest + Patch - "version" Command Hangs

[Frank Hemer]

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