[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3] tee: handle EAGAIN returned from fwrite/fclose()
From: |
Kamil Dudka |
Subject: |
Re: [PATCH v3] tee: handle EAGAIN returned from fwrite/fclose() |
Date: |
Mon, 05 Nov 2018 14:00:54 +0100 |
On Monday, November 5, 2018 12:54:25 PM CET Pádraig Brady wrote:
> On 01/11/18 07:39, Kamil Dudka wrote:
> > On Tuesday, September 11, 2018 3:05:20 PM CET Kamil Dudka wrote:
> >> 'tee' expected the output file descriptors to operate in blocking mode
> >> but this assumption might be invalidated by other programs connected to
> >> the same terminal, as in the following example:
> >>
> >> $ telnet ... | tee log_file
> >>
> >> telnet calls ioctl(stdin, FIONBIO, [1]), which causes the O_NONBLOCK
> >> flag to be set on tee's output, which is connected to the same terminal.
> >>
> >> This patch has zero impact unless EAGAIN returns from fwrite/fclose().
> >> In that case 'tee' waits for the underlying file descriptor to become
> >> writable again and then it writes the remaining data.
> >
> > Are there still any concerns about the last version of this patch?
> >
> > Is there anything I can do to move this forward?
>
> I still don't see why tee is special here,
> compared to any other filter.
It is just the most common utility one would use with telnet-like programs.
I could extend the patch for other utilities, too, but I am afraid that it
would not increase the chance of the patch being accepted in the end.
> The infinite timeout poll() also worries me.
Why? In the usual case where stdout operates in blocking mode, fwrite()
may also block indefinitely. The patch just makes 'tee' behave equally
in both the modes to avoid unnecessary surprises at user's side.
> There were also the 4 other possible options
> I mentioned in the thread for avoiding the issue.
Thanks! I will forward them to the affected users.
Kamil
> I'm not too enthusiastic for this one, sorry.
>
> Pádraig