bug-cvs
[Top][All Lists]
Advanced

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

Re: Lost process output in pipe between Emacs and CVS


From: Derek Robert Price
Subject: Re: Lost process output in pipe between Emacs and CVS
Date: Wed, 24 Jul 2002 13:23:11 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606

kevin wang wrote:

From Richard Stallman
     If a buffer flush fails with EAGAIN during
   printf, what should happen?

printf should retry, perhaps after a short sleep, and thus more or
less emulate the behavior with an ordinary blocking descriptor.

If you want to emulate blocking behaviour, then why not USE blocking
behaviour?

Please see my previous email. The issue is that a file descriptor became non-blocking without CVS noticing. CVS expects blocking behavior and normally, that's what it gets.

It doesn't make any sense to make the default behaviour of non-blocking
act like blocking.

I believe this proposal would only affect stdio. Since they currently lose data in such a way as to make recovery difficult, why not write guaranteed delivery of data to non-blocking descriptors into their charter without rewriting the API?

Now if you wanted to write a library that emulated 'soft-non-blocking'
i.e.  retry in a little bit, with a timeout, sure that would be fine,
but blocking is blocking and non-b is non-b. anything inbetween should
be a separate mode.

If you're worried about printf, then use sprintf, dump it to a buffer,
and then feed it out stdio yourself (or with a library or whatever).

If all stdio output functions handle EAGAIN by sleeping for a short time
and trying again, most user programs will be happy with the results.
The few that are not happy are those that should not use stdio.

I disagree.  sleeps are inherently evil.  stdio is not 'special' that it
needs different handling characteristics than any other file descriptor.
What if stdio had been instead mapped to a file?  a pipe?  The app simply
cannot tell the difference, and simply cannot be told to act differently
because it's stdio

And your app doesn't care that the stdio functions don't return proper status when writing to non-blocking descriptors? The issue is that printf and its ilk can write partial data. You could check for EAGAIN, but you still wouldn't know how much of the data had been written to a file, pipe, tty, or whatever. The app can't know how much to resend. Do you desire that behavior? Making the stdio routines always behave as if descriptors are blocking (as far as the calling function is concerned) seems reasonable.

Derek

--
               *8^)

Email: address@hidden
Public key available from www.keyserver.net - Key ID 5ECF1609
Fingerprint 511D DCD9 04CE 48A9 CC07  A421 BFBF 5CC2 56A6 AB0E

Get CVS support at http://2-wit.com
--
I will not grease the monkey bars.
I will not grease the monkey bars.
I will not grease the monkey bars...

         - Bart Simpson on chalkboard, _The Simpsons_






reply via email to

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