-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Frank Hemer wrote:
|> The basic problem, as Frank Hemer has described it, is that there |> are some conditions where the Windows client can expect to be in |> non-blocking mode yet fail to really be in non-blocking mode, |> causing a hang. Frank has yet to send a script reproducibly |> demonstrating the failure. | | | If you send me any script (for a different problem) that | demonstrates what kind of script you expect I'll do my very best | ...
A series of commands that a naive user could type in and see the failure should suffice. This should include creating the files in the repository necessary to demonstrate the problem.
Normally, a script snippet which can fit into the src/sanity.sh script is ideal, but that doesn't currently run properly on Windows anyhow, so for now, the series of commands should suffice.
|> The most offending code is in fd_buffer_block(), also in |> buffer.c. You can see where it is called above. |> fd_buffer_block() will currently happily fail to set non-blocking |> mode then mark the data structure as non-blocking anyhow and |> return a success code. It skips setting the block mode if it |> can't find any of three POSIX macros, F_GETFL, O_NONBLOCK, or |> F_SETFL (determined at compile time). |> |> If you read the header comment of fd_buffer_input(), it notes |> that the special blocking semantics being implemented are |> important in at least some circumstances, so it would be |> best/easiest if we could imitate the POSIX fcntl() & O_NONBLOCK |> semantics in fd_buffer_block(), but, as a last resort, perhaps |> the read() calls could be abstracted out into |> read_blocking()/read_nonblocking() wrappers called from |> fd_buffer_input(). | | | The problem is not a hang. The win-posix implementation does only | allow a select on a socket. In :ext: mode, the fd points to a pipe | and select returns WSAENOTSOCK. The result is not a hang but an | error report saying: no such file (at least when called with cvs | status) because the read never gets executed.
This might be trouble then. If we really can't select on the pipe, we can't use the current fd_buffer_input implementation. We'd have to fall back on the old, less efficient implementation: in blocking mode, perform a blocking read of a single byte no matter how many bytes the caller requested.
Regards,
Derek -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCGKawLD1OTBfyMaQRAtO1AJ4uXCwVXm57cqCWcGjbD1oW/XG5+wCgwVsA r0qB7ve8xuyuk9c3XtXz4pc= =X+od -----END PGP SIGNATURE-----
_______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
