bug-cvs
[Top][All Lists]
Advanced

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]