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

[Frank Hemer]

On Sunday 20 February 2005 16:03, you wrote:
> -----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.

Because the problem appears without any cvs action taking place, the following 
should suffice:

cvs -d C:\my-cvs-root-dir init
export CVS_RSH=plink
cvs -d :ext:user@localhost:C:\my-cvs-root-dir rls .

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

Well, this might be an option. I don't have an idea whether there are more os 
that cannot change a fd to nonblocking. If so (and that was my intention for 
the patch), this situation could be handled in fd_buffer_input().
Regarding the header comments for fd_buffer_input() ... hmm, on win it seems 
to behave as described, no idea about other os without nonblocking ...

Regards,
Frank