[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky
The following reply was made to PR install/56303; it has been noted by GNATS.
From: Andreas Gustafsson <gson%gson.org@localhost>
To: RVP <rvp%SDF.ORG@localhost>
Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>,
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky
Date: Thu, 26 Aug 2021 18:45:16 +0300
> >> Re: progress.c 1.24: This test which you modified is not needed:
> >> if (deadpid == -1 && errno == EINTR)
> >> continue;
> >> By ths point all read/writes have finished, and `outpipe' has
> >> been closed. So you can stop the progress bar code right after the
> >> `while (1)' loop and no interrupts can occur. This is what my
> >> initial patch did.
> > Closing outpipe eliminates one source of signals, but I don't see
> > any obvious way of proving that there can be no others.
> Not sure what you mean here: Only caught signals (ALRM and PIPE--but the
> PIPE handler causes a termination) can cause wait() to return an EINTR.
> If the progress bar is turned off, and there are no writes, wait() can't
> come back with a -1 and EINTR.
Yes, _if_ the progress bar has been turned off at that point, but that
is not currently the case. It would be the case if we also applied
one of your other changes, moving the progressmeter(1) call to before
the wait() calls, but I don't think that change is a good idea; it
would cause the progress command to indicate that the operation is
complete before the "cmd" has actually finished, and the final
transfer rate estimate would no longer account for the full execution
time of the "cmd".
> The diff is slightly large, but, most of the changes are simple, obvious
> ones, and the core logic is practically the same, so hardly a wholesale
By "wholesale replacement", I was referring to sending a complete
source file as opposed to patches.
> On Fri, 20 Aug 2021, Christos Zoulas wrote:
> > That's a good change, replacing a non-portable ioctl call with a posix
> > terms function call.
> That was the intent, yes.
Since Christos supports that change, perhaps you can ask him to commit it.
In any case, it is outside scope of the present (closed) PR.
Andreas Gustafsson, gson%gson.org@localhost
Main Index |
Thread Index |