Re: Lost process output in pipe between Emacs and CVS

[Derek Robert Price]

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: derek@2-wit.com
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_