Update of bug #67390 (group groff):
Assigned to: gbranden => deri
_______________________________________________________
Follow-up Comment #4:
The commit Deri said he made in comment #1 seems not to have been pushed yet.
Reassigning to him.
Also, some of Deri's and my exchange on this ticket seems to have gone
missing. It happened the same day GNU-related mails seemed to be delayed by
several hours, so maybe that has/had something to do with it.
I rescued the following from my sent folder.
> Phew! Thought you meant the code was not working. By "too bullish
> again, ignoring signals" you actually meant you did not want to wait
> "a few seconds" for it to act on the signal on an incredibly slow
> machine.
More precisely, what happened is that "BuildFoundries" noted that
afmtodit exited with a failure status, but all it did with that
information is set a flag to be consulted later; it continued to iterate
over its argument list.
If the _rm_(1) command worked that way, single-mindedly iterating over
its entire argument list regardless of incoming fatal signals, telling
the user only at the end of its work that "oh, by the way, some fool
attempted to interrupt me", traditional Unix users would revolt.
(Modern ones might not, admittedly, and resign themselves to total data
destruction because even disk access is much faster than it used to be.
https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html
)
> Perhaps you could amend the bug title to something more
> appropriate. It must take minutes to do a full make clean; configure;
> make; make check; make distcheck - I feel for you.
I don't agree with your interpretation: by not checking the (full,
system-level) exit status of the process you're spawning, you're
throwing away information irrecoverably. Also, on general application
design principles, unless a program has a good reason to be ignoring or
blocking a symbol, it should respond to that signal immediately.
(Generally, if it has a good reason to not use a signal's default
behavior--in most cases, dying--it should install a handler for the
signal that sets a global flag that the main program logic routinely
checks, and which causes the program to gracefully but expeditiously
release resources and exit, often with a failure status.)
I've come to expect interactive builds to be responsive to fatal
signals. I don't think my experience is unusual.
So, to me, "ignoring signals" in this application implies "too bullish".
[snip]
> I shall reply over there, probably toomorrow.
Looking forward to it. Note James Cloos's reply on the groff list;[*]
it sounds like I may have started down an incorrect path regarding these
overloaded Greek glyphs. His reply may save you the trouble of
correcting me yourself.
[*] https://lists.gnu.org/archive/html/groff/2025-08/msg00000.html
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67390>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
