Clearing O_NONBLOCK from a pipe may lose data
Mon Feb 23 12:10:00 GMT 2015
On Feb 21 18:44, Thomas Wolff wrote:
> Am 20.02.2015 um 11:13 schrieb Corinna Vinschen:
> >On Feb 20 08:56, Thomas Wolff wrote:
> >>By flushing I meant actually waiting until it's been consumed at the
> >>other end in this case, if that's technically feasible.
> >You mean the actual act of changing the descriptor from non-blocking
> >to blocking, as in fcntl(fd, F_SETFL), shall perform the same action
> >of waiting as the close call on non-blocking descriptors does?
> >>I see no strict requirement that the fcntl call removing O_NONBLOCK from
> >>a file descriptor should itself still be handled as nonblocking (it can
> >>well be argued that the flag is changed first and then the call is
> >>allowed to block) - and even if this were not proper it is certainly
> >>more acceptable than losing data.
> >I'm not sure that works as desired, but it's probably worth a try. An
> >fcntl method for pipes has to be added (there is none yet, it's all done
> >in fhandler_base::fcntl), then the F_SETFL command would have to be
> >augmented to create a thread calling FlushFileBuffers (which is
> >*supposed* to work on pipe handles but I never tried it myself), and the
> >fcntl call would have to wait for thread completion, allowing
> >interruption by signals (calling cygwait, that is).
> where the actual code (as I understood you) could be copied from close()
> code. Although I looked into the code and didn't find the place where close
> would lead to FlushFileBuffers...
close doesn't call FFB. It just calls a waiter thread waiting for all
async writes on pipes to be finished. It doesn't handle a single pipe,
that's why this has to be implemented differently.
> >The question with stuff like this is usually, how long are you willing to wait?
> > You never know what the reader side of a pipe is doing. It
> >might just be busy and intends to read from the pipe in a second, a
> >minute, or an hour.
> ... like it is normal when feeding a pipe in blocking mode (which we just
> switched to). I don't see a problem here.
You have a point there.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Cygwin