Applications that inherit from TRint and SIGINT

ROOT
1

Dear All,

It appears that sending a SIGINT to TRint no longer works as described. It is my understanding from recent forum posts like https://root-forum.cern.ch/t/cannot-interrupt-root-process/27329 that it is intended that sending a SIGINT to a TRint application should clear the current line and reset the prompt. This is the observed behavior, however this behavior cannot be changed.

In all version of ROOT5 and early versions of ROOT6 one could use the provided public functions of TRint to replace the default signal handler. This process is well documented in what appears to be both current root documentation(section 25.4 of https://root.cern.ch/root/htmldoc/guides/users-guide/Threads.html) and numerous forum posts (for example: https://root-forum.cern.ch/t/ctrl-c-singal-handler-under-win32-platform/11702).

However, at some point around root version 6.10 through the present(6.21/01 as the writing of this post), one can not change the default behavior of SIGINT. Through trial and error, I suspect that in fact the TInterruptHandler created inside of the TRint constructor is never used. I came to this conclusion by modifying the TInterrputHandler::Notify function (commenting out everything but a single print statement followed by an fflush to stdout), recompiled root - this change has no effect on SIGINT behavior.

I doubt this expected behavior. It seems to me that being able to change the default behavior of system signals like SIGINT is useful functionality for a user program inheriting from TRint should be able to control. Any insights would be much appreciated.

Thanks,
Peter

Please read tips for efficient and successful posting and posting code

_ROOT Version: 6.21
_Platform: Scientific Linux 7 and MacOS
_Compiler: tested on both g++ (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3) and Apple LLVM version 10.0.1 (clang-1001.0.46.4)

2

Hi Peter,

totally agreed! I will see if I can find the expert on TRint.

@Axel maybe?

Also see ROOT-9906

3

Hi Peter,

thanks for your report. Could you state on which context this bug is affecting you? (We have very, very few people being able to work on these issues, so we need to prioritize brutally, and for that I’d like to understand the extend of tragedy that this bug causes…)

Thanks!
Axel.

4

Hi Alex (and StephanH),

Thank you for your reply. I appreciate the limited number team able to work on core issues. The under lying cling structure is complicated to say the least. The issue arises that any program where an interpreter is created simple ignores SIGINT, SIGQUIT and SIGTSTP if SIGINT suggests clang itself is catching signals rather than TRint. I personally have not found/understood where or how this is being handled in code (and hence am not much help in debugging the problem).

To me personally, this is a library breaking feature. I have written and help maintain a number of large sorting/analysis routines for the low energy nuclear physics community. The TRint inherited class is started to allow the user to maintain access and control of the various sorting loops as well as do “on the fly” analysis. Taking away the ability to send various signals to the program which can be predictably respond to (like stop sorting, clean up and save progress) has been a huge time sink.

I can revert back and only use an older version of ROOT if a solution cannot be found. However considering the large amount of documentation which exists on the web on how to write custom handlers for SIGINT for TRint, we as a community should clearly document somewhere that this feature and these functions simply do not work.

Thanks,
Peter

5

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

6

Thanks, Peter. Does this affect an experiment, a physics group - in which context are these “large sorting/analysis routines” being deployed?

Cheers, Axel.