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