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: Frank Hemer
Subject: Re: :ext: with ssh failure on w2k - patch
Date: Sun, 20 Feb 2005 15:50:53 +0100
User-agent: KMail/1.5.1

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

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

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.

Regards,
Frank




reply via email to

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