[Top][All Lists]

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

Re: Why does close_stdout close stdout and stderr?

From: Paul Eggert
Subject: Re: Why does close_stdout close stdout and stderr?
Date: Fri, 24 May 2019 18:41:15 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 5/13/19 12:00 AM, Florian Weimer wrote:
I don't see any way around this problem in general with the closeout
module's current API, because when it discovers an I/O error it calls
_exit, and _exit also clashes with that kind of cleanup handling.
This isn't the problem.  fflush may also realistically cause SIGPIPE to
be delivered to the process.  That's all fine.

It might be fine for some of these environments, but surely it can't be fine for others. If I'm relying on the startup routines to issue some sort of report for any non-signalling exit, then calls to _exit will bypass the report.

Look at the existing workaround
for sanitizers, and the comment in close_stream.  The code is buggy

I agree the code is a hack. But it's not buggy: it's portable to any environment that conforms to POSIX, and that's a wide variety of environments. The problem seems to be that people want to run these applications in debugging environments that don't conform to POSIX. While I'm sympathetic to that goal, it's not a high-priority-enough situation to call the current code "buggy".

A better fix here would not be to pile yet another hack into this hacky module. It would be to write a better module (we could call it "flushout", say) that would define a function ("flushout_stream", say) that would act like fflush but would do a better job with NFS-based streams by playing the dup+close+fsync trick. We could then modify coreutils etc. to use this new module instead of the old one. The hard part is the "modify coreutils etc." part, because flushout_stream will be less convenient to use than the current API.

reply via email to

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