There were a few things that were going wrong here. First of all we didn't properly (re)initialize the state when starting LLVM after we stopped it before execvp'ing. It was still seeing that a stop was requested, so we should reset that. Another issue is that we use removed the global reference to the signal handler when stopping, causing a crash if a signal was going to be processed after a failed exec. We introduce a pause() for the SignalHandler so we can easier restart it later on. Another issue is that the semantics of signal() regarding SA_RESTART are different from what signaction() does. We need to have SA_RESTART otherwise calls to for example read() or accept() are not interuptable and thus can cause a hang. Using sigaction() makes sure we set up the default handlers properly so we can recover later on without problems. After these changes, enabling the problematic Kernel#exec specs still cause a crash, but that only happens when running 'rake' and not when running for example ./bin/mspec ci. This needs further investigation.
MRI also exits if you exit from another thread than the main thread. In this case we have to be sure to shutdown everything properly, since only the main thread exiting will also take down all other running threads.
Otherwise we lack signal handler in a process that tried to do an execvp() and failed. We mark the SignalHandler thread as not deleting the thread when it exits, since we might need to restart it. This isn't a risk for a leak, since we never deallocate the SignalHandler in a process anyway.
Conflicts: kernel/bootstrap/rubinius.rb vm/builtin/system.cpp vm/builtin/system.hpp vm/signal.cpp vm/signal.hpp
This makes sure the signal never even arrives at the process. Fixes #995
Also use pthread_equal over direct comparisons as recommended
Signals that raised an exception weren't noticed because the signal processing didn't explicitly state whether it succeeded or not. This change allows the process to pick up these exceptions and act accordingly.