[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: :ext: with ssh failure on w2k - patch
From: |
Derek Price |
Subject: |
Re: :ext: with ssh failure on w2k - patch |
Date: |
Sun, 20 Feb 2005 09:15:08 -0500 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Conrad T. Pino wrote:
| At the Windows 32-bit API level, blocking vs. non-blocking has no
| real meaning because ALL file handles are non-blocking. All I/O
| functions have blocking and non-blocking implementations. The
| developer chooses blocking behavior by choosing the appropriate API
| function.
|
| CVS has problems because it is NOT written to use the Windows
| 32-bit API. CVS is written to the Windows POSIX layer which is
| known to be a poor POSIX implementation.
|
| I don't claim to understand this issue but if someone can point out
| the problem code and make a clear statement about the desired
| behavior that is needed from the Windows API then I'll commit some
| time to making code suggestions.
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.
Frank reports that the code that hangs begins like this in the
fd_buffer_input() function in buffer.c:
~ if (fb->blocking)
~ {
~ int status;
~ fd_set readfds;
~ /* Set non-block. */
~ status = fd_buffer_block (fb, false);
~ if (status != 0) return status;
~ FD_ZERO (&readfds);
~ FD_SET (fb->fd, &readfds);
~ do
~ {
~ int numfds;
~ do {
~ /* This used to select on exceptions too, but as far
~ as I know there was never any reason to do that and
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().
Regards,
Derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCGJtrLD1OTBfyMaQRAljoAJ9IgC+YljY0IHv0MWq5BmCuZ/WffgCg76Zk
VjYOeag6ID/kjjQJBj41O4s=
=vbak
-----END PGP SIGNATURE-----