[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Windows CVS Latest + Patch - "version" Command Hangs

From: Conrad T. Pino
Subject: RE: Windows CVS Latest + Patch - "version" Command Hangs
Date: Sat, 24 Sep 2005 22:37:22 -0700

> 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:
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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]