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 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 > correctly, the results should be correct. That depends on your definition of "correctly". I suspect that all stdio implementations handle short writes by immediately doing another write for the remaining data, which in this case will immediately fail with EAGAIN and we're back to where we started. > If the current fix does not make it correct, please do make the larger > fix--do your own buffering. That is surely not really a large job. Replacing stdio isn't a large job?!? > As this case shows, other > processes that share the descriptor have the reasonable expectation > that they can take an inherited descriptor and make it non-blocking. That is an entirely *un*reasonable expectation. Like I said before, nonblocking mode does not affect the descriptor, it affects the underlying file and it violates all of the conventions of how files are supposed to behave. Thus, it cannot reasonably be used except under very tightly controlled conditions -- when you know that you have exclusive use, not just of the descriptor, but of the underlying file. Typically, it's used on newly-created sockets, which do satisfy those conditions. Ssh is trying to use it on standard descriptors that it inherits from an unknown source that almost certainly do not satisfy those conditions. That's just plain wrong. Note that rsh has always worked just fine without using non-blocking mode for *anything*, ssh should certainly be able to get away without using it on its standard files. > Rather that deciding what to fix by first placing blame, we can do > better if we look at how we can contribute to making the system work. Agreed, which is why we adopted the workaround. But it's not "placing blame", it's determining the root of the problem. > The right program to fix, in a case like this, is whichever one we > actually can get fixed. No, the right program to fix is the one that's broken: ssh. -Larry Jones Whatever it is, it's driving me crazy! -- Calvin _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
