Re: :ext: with ssh failure on w2k - patch

[Derek Price]

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