[io] Prevent losing data due to SIGTERM (under Unix)

[ferdymercury]

This Pull request:

Changes or fixes:

Fixes #13300

• I tested this locally on Ubu22 and it works fine.
• I do not know how to properly test it using GTEST, I only found test_polling.cxx doing something like that but it looked too complicated, so I ended up simplifying.
• I do not know if Windows must catch SIGTERM somewhere else @bellenot ?

Checklist:

• tested changes locally
• updated the docs (if necessary)

[github-actions]

Test Results

    22 files      22 suites   3d 18h 35m 56s ⏱️
 3 707 tests  3 660 ✅ 0 💤 47 ❌
79 603 runs  79 509 ✅ 0 💤 94 ❌

For more details on these failures, see this check.

Results for commit 64374c4.

♻️ This comment has been updated with latest results.

[bellenot]

@ferdymercury The SIGILL and SIGTERM signals aren't generated under Windows. They're included for ANSI compatibility. See the signal reference

[dpiparo]

Let's have a look to the tests once again

[pcanal]

If I understood correctly, this would mean that after code similar to:

root [] TFile f(filename, RECREATE);
root [] do_stuff();
root [] if (all_is_well) f.Write();

We have a different behavior if the user does:

root [] .q

and

send SIGTERM

Where the former does not write the file while the later would now write the file.

[ferdymercury]

Yes.

[dpiparo]

As I tried to explain here, #13300 (comment), I think this is a logical behaviour. The prompt experience does not change. The behaviour if SIGKILL is used does not change. However, if SIGTERM is used, some kind of "soft termination" that gives the process a way to wrap up and end gracefully, is the right thing to do.

[ferdymercury]

We could create a ".wq" ROOT command (one char longer than ".q") to do the equivalent of save and exit as if it were vim, if one wants to rely on this without having to look how to send SIGTERM. Or just for symmetry with SIGNALS.

[dpiparo]

I would be in favour of approving, @pcanal , but only if you also agree with the point I made above.