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:[EMAIL PROTECTED]: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 _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
