If the problem occurs with fflush, most likely it will also occur
with fwrite, fclose, etc. fflush is merely the guinea pig here.
We may have to send bug reports for the systems where it does not always work.
However, even on those systems, this is change likely to be a big improvement.
Richard M. Stallman writes:
We may have to send bug reports for the systems where it does not always work.
That's essentially *ALL* of them. How many time do I have to say it --
nonblocking mode violates the fundamental assumtions about how files are
supposed to behave and virtually *no*
That's essentially *ALL* of them. How many time do I have to say it --
nonblocking mode violates the fundamental assumtions about how files are
supposed to behave
It didn't convince me the first time, and repeating it won't convince
me either. We need to get this bug fixed, and
Richard M. Stallman writes:
If you prefer a different fix that _can be done by us_, that's fine
with me. Just as long as we fix the problem.
WE CAN'T FIX THE PROBLEM.
Nothing you do to the car can fix the potholes in the road. You can
spend all the time and money you want upgrading the
I just checked FreeBSD libc, and it appears that fflush fails once its
underlying write fails with EAGAIN. So it appears that this approach
won't work under FreeBSD. That's not a good sign.
Isn't that a bug in FreeBSD?
We can try to work around bugs in various systems, but it is
Richard M. Stallman [EMAIL PROTECTED] writes:
I am not sure what job that program does. The program is too long for
me to read it just to try to figure that out.
The program arranges for fflush to have a nontrivial amount of
buffered data to flush. It then calls fflush, so the buffer is then
I wrote the code, checking the specs, and got it to compile correctly.
I don't have any easy way to test it--Emacs is not well suited to that
purpose. Could you test it?
/* The idea of this module is to help programs cope with output
streams that have become nonblocking.
To use it,
Richard M. Stallman wrote:
I wrote the code, checking the specs, and got it to compile correctly.
I don't have any easy way to test it--Emacs is not well suited to that
purpose. Could you test it?
You neglected to include a wrapper for at least fflush().
subst_fwrite (buffer, 1,
Richard M. Stallman writes:
If this is what it takes for you to fix the bug, I will do this.
Instead of spending large amounts of effort on half-assed workarounds,
why don't you make a concerted effort to explain the problem to the
OpenSSH developers and encourage them to fix the actual
Not exactly. If a solution like this were to go into GLIBC, then it
becomes much more likely that it can be shared with GNULIB, which means
that the infrastructure for it is already in CVS and that supporting it
won't rely exclusively on the extremely small and overworked CVS
Larry Jones wrote:
Richard M. Stallman writes:
If this is what it takes for you to fix the bug, I will do this.
Instead of spending large amounts of effort on half-assed workarounds,
why don't you make a concerted effort to explain the problem to the
OpenSSH developers and encourage
Richard M. Stallman wrote:
Not exactly. If a solution like this were to go into GLIBC, then it
becomes much more likely that it can be shared with GNULIB, which means
that the infrastructure for it is already in CVS and that supporting it
won't rely exclusively on the extremely
Richard M. Stallman wrote:
Why not have glibc incorporate the moral equivalent of the unlocked
stdio routines (fwrite_unlocked, printf_unlocked, etc.), like
fwrite_block?
I am not sure what unlocked means,
I'm referring to the non-thread-safe stdio variants exported by glibc
and
Why not have glibc incorporate the moral equivalent of the unlocked
stdio routines (fwrite_unlocked, printf_unlocked, etc.), like
fwrite_block?
I am not sure what unlocked means, but any solution like this would
only work on GNU. It would be better to use an equally simple
approach
Why not have glibc incorporate the moral equivalent of the unlocked
stdio routines (fwrite_unlocked, printf_unlocked, etc.), like
fwrite_block? Similarly for printf_block, fprintf_block, etc. Most of
the stdio code would not need to be reimplemented since it is already
present in glibc and
Richard M. Stallman wrote:
Currently CVS does a single select on the stdout fileno
before dumping as much data as it last received from the network to
stdout via fwrite. There is *no looping or checking for EAGAIN
returns*, which I believe you advocated but, I am informed by
could not do any harm on any system. If it fixes the problem on GNU
systems, that's an important improvement, so why not do it?
It might not do any additional harm. I won't claim to understand the
issue completely, but I was told that there might be data loss since
Richard M. Stallman wrote:
The code currently works by making the assumption that network reads
will always return chunks of data small enough to be written to stdout
in a single call to fwrite after a single select on fileno (stdout).
What would make some data too long? The nmemb
Currently CVS does a single select on the stdout fileno
before dumping as much data as it last received from the network to
stdout via fwrite. There is *no looping or checking for EAGAIN
returns*, which I believe you advocated but, I am informed by Larry
Jones and Paul
The code currently works by making the assumption that network reads
will always return chunks of data small enough to be written to stdout
in a single call to fwrite after a single select on fileno (stdout).
What would make some data too long? The nmemb argument of fwrite is a
It's possible that this fix is a full and correct solution. If the
descriptor has room for at least one byte, `write' won't return
EAGAIN; it will write at least one byte. It may write less than the
whole buffer that was specified. If the stdio code handles that case
It's possible that this fix is a full and correct solution. If the
descriptor has room for at least one byte, `write' won't return
EAGAIN; it will write at least one byte. It may write less than the
whole buffer that was specified. If the stdio code handles that case
* 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
Richard M. Stallman writes:
I'm glad to hear that the new CVS version has a fix that may prevent
the problem. Maybe this problem is fixed now. But we should verify that.
It's not a fix, it's a temporary workaround that avoids the problem in
some, but not all, cases.
It's possible that
Richard M. Stallman wrote:
It's possible that this fix is a full and correct solution. If the
descriptor has room for at least one byte, `write' won't return
EAGAIN; it will write at least one byte. It may write less than the
whole buffer that was specified. If the stdio code handles that case
On Tuesday 21 June 2005 17:13, Richard M. Stallman wrote:
I am trying to bring about a fix for the bad interaction between
CVS and SSH that causes data to be lost?
See http://lists.gnu.org/archive/html/bug-cvs/2002-07/msg00423.html
for a good explanation.
After studying that message, I
Richard M. Stallman writes:
I am trying to bring about a fix for the bad interaction between
CVS and SSH that causes data to be lost?
See http://lists.gnu.org/archive/html/bug-cvs/2002-07/msg00423.html for
a good explanation.
After studying that message, I think I understand the
Richard M. Stallman wrote:
Couldn't this be fixed easily by changing cvs to handle EAGAIN
in a simple way when outputting to stdout? If it just sleeps for a second
and tries again, that ought to fix the problem.
Mark Baushke installed Frank Hemer's partial work-around for this
problem some
28 matches
Mail list logo
