bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS update [cvs1-11-x-branch]: /ccvs/src/


From: Derek Robert Price
Subject: Re: CVS update [cvs1-11-x-branch]: /ccvs/src/
Date: Wed, 25 Aug 2004 14:46:41 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

address@hidden wrote:

>Tag: cvs1-11-x-branch
>User: mdb     
>Date: 04/08/17 18:12:30
>
>Modified:
> /ccvs/src/
>  ChangeLog, client.c, sanity.sh
>
>Log:
> * client.c (handle_m): Workaround to deal with stdio getting put
> into non-blocking via redirection of stderr and interaction with
> ssh on some platforms. On those boxes, stdio can put stdout
> unexpectedly into non-blocking mode which may lead to fwrite() or
> fflush() failing with EAGAIN, but cvs not checking for the error.
> (Patch suggested by Frank Hemer <address@hidden>.)
>
> * client.c (handle_e): Similar fix for stderr.
> * sanity.sh (sshstdio): New test for non-blocking stdio via ssh.
>
>File Changes:
>
>Directory: /ccvs/src/
>=====================
>
>File [changed]: ChangeLog
>Url:
https://ccvs.cvshome.org/source/browse/ccvs/src/ChangeLog?r1=1.2336.2.290&r2=1.2336.2.291
>Delta lines:  +12 -0
>--------------------
>--- ChangeLog    11 Aug 2004 17:13:19 -0000    1.2336.2.290
>+++ ChangeLog    18 Aug 2004 01:12:24 -0000    1.2336.2.291
>@@ -1,3 +1,15 @@
>+2004-08-17  Mark D. Baushke  <address@hidden>
>+
>+    * client.c (handle_m): Workaround to deal with stdio getting put
>+    into non-blocking via redirection of stderr and interaction with
>+    ssh on some platforms. On those boxes, stdio can put stdout
>+    unexpectedly into non-blocking mode which may lead to fwrite() or
>+    fflush() failing with EAGAIN, but cvs not checking for the error.
>+    (Patch suggested by Frank Hemer <address@hidden>.)
>+
>+    * client.c (handle_e): Similar fix for stderr.
>+    * sanity.sh (sshstdio): New test for non-blocking stdio via ssh.
>+    
> 2004-08-11  Derek Price <address@hidden>
>
>     * sanity.sh (basicc): Work around a problem in Linux 2.2 & Bash
2.05b
>
>File [changed]: client.c
>Url:
https://ccvs.cvshome.org/source/browse/ccvs/src/client.c?r1=1.318.4.20&r2=1.318.4.21
>Delta lines:  +22 -0
>--------------------
>--- client.c    26 Apr 2004 15:52:05 -0000    1.318.4.20
>+++ client.c    18 Aug 2004 01:12:24 -0000    1.318.4.21
>@@ -3068,6 +3068,9 @@
>     char *args;
>     int len;
> {
>+    fd_set wfds;
>+    int s;
>+
>     /* In the case where stdout and stderr point to the same place,
>        fflushing stderr will make output happen in the correct order.
>        Often stderr will be line-buffered and this won't be needed,
>@@ -3075,6 +3078,11 @@
>        based on being confused between default buffering between
>        stdout and stderr.  But I'm not sure).  */
>     fflush (stderr);
>+    FD_ZERO (&wfds);
>+    FD_SET (STDOUT_FILENO, &wfds);
>+    s = select (STDOUT_FILENO+1, NULL, &wfds, NULL, NULL);
>+    if (s < 1)
>+        perror ("cannot write to stdout");
>     fwrite (args, len, sizeof (*args), stdout);
>     putc ('\n', stdout);
> }
>@@ -3122,9 +3130,23 @@
>     char *args;
>     int len;
> {
>+    fd_set wfds;
>+    int s;
>+
>     /* In the case where stdout and stderr point to the same place,
>        fflushing stdout will make output happen in the correct
order.  */
>     fflush (stdout);
>+    FD_ZERO (&wfds);
>+    FD_SET (STDERR_FILENO, &wfds);
>+    s = select (STDERR_FILENO+1, NULL, &wfds, NULL, NULL);
>+    /*
>+     * If stderr has problems, then adding a call to
>+     *   perror ("cannot write to stderr")
>+     * will not work. So, try to write a message on stdout and
>+     * terminate cvs.
>+     */
>+    if (s < 1)
>+        fperrmsg (stdout, 1, errno, "cannot write to stderr");
>     fwrite (args, len, sizeof (*args), stderr);
>     putc ('\n', stderr);
> }


Hey Mark,

This is better than before and it would probably take a larger file
than you built in sanity.sh to prove it, but I believe this can still
lose data.  Just because select returned ready for the file descriptor
doesn't mean that the descriptor is necessarily ready for LEN bytes of
data.  fwrite() is defined to return the number of bytes written.
Assuming that works when the file is in non-blocking mode, then this
code will probably need to loop over remaining bytes until everything
is written.

CC'ing bug-cvs in case anyone can correct me or expound.

Cheers,

Derek

- --
                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBLN6QLD1OTBfyMaQRAgdAAKCtF1lH4KZMEZBwQWew9UzwCj3hFACeP8ut
//PGC359SjQSRyT3KWdAWPI=
=z/jM
-----END PGP SIGNATURE-----





reply via email to

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