Please don't set up signal handler by default in the library

Linux
1

Well, as title says, I wouldn’t except the library to mess up with signal handlers.
I think it would be a good idea to be able to enable / disable such thing (the juce way, not by setting up a dummy signalHandler if we want to disable it), in the initialise method for example, or in the first DesktopWindow instance.
Signal are not like virtual method, when I install my handler, there’s no way to call back yours (or only with hacky asm tricks to fool the instruction pointer to point on yours).

As I’m installing handlers in the very very early step for minidump reasons, Juce’s overwriting them with theirs and there’s a long time before I can overwrite them again.

2

Up ?

3

The signal handler is there to allow the app to terminate gracefully if it receives a keyboard break. If that’s not important to you, you could just change the handler to your own routine after start-up, and not worry about calling mine.

4

I don’t mind the keyboard handler. The lib catches many more signals than SIGINT however, which I care about.

I’m doing this:

struct MinidumpInstaller
{
    MinidumpInstaller() // Install signal handlers
    ~MinidumpInstaller() // Uninstall them;
};
static MinidumpInstaller signalHandlerInstaller;

// JUCE MAIN

App::initialise()
{
     // Reinstall signal handler
     [...]     
}

I’m already overwriting them in my initialise method again (but this is ugly), but for the whole time between main and initialise, I’m naked.
What about this then (juce_linux_Messaging.cpp: 251) :

-#ifndef _DEBUG
    // Setup signal handlers for various fatal errors
#if !(JUCE_SIGNAL_MASK & 1)
    sigaction (SIGILL, &saction, NULL);
#endif
#if !(JUCE_SIGNAL_MASK & 2)
    sigaction (SIGBUS, &saction, NULL);
#endif
#if !(JUCE_SIGNAL_MASK & 4)
    sigaction (SIGFPE, &saction, NULL);
#endif
#if !(JUCE_SIGNAL_MASK & 8)
    sigaction (SIGSEGV, &saction, NULL);
#endif
#if !(JUCE_SIGNAL_MASK & 16)
    sigaction (SIGSYS, &saction, NULL);
#endif
-#endif

// Somewhere in juce_macros
#ifndef JUCE_SIGNAL_MASK
   #ifndef _DEBUG 
      #define JUCE_SIGNAL_MASK 0
   #else
      #define JUCE_SIGNAL_MASK 0xFF
   #endif
#endif

This will not change current user code behaviour, but allow me (us?) to enable only the signal handler we want.

Also, what is the reason why they are disabled in debug builds ?

5

Hmm. I hadn’t looked at that code for a very long time, so just had a look again, and I don’t actually know why any of those signals are enabled at all - I think I should remove everything apart from the keyboard break handler. The code looks like the remnants of some old linux code that was contributed a long time ago when I was just starting the linux port.

6

Ok, it’s great then.

7

Ok, it’s gone now. That file needed a bit of a spring-cleaning.