-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of signal handlers needs to be improved #15
Comments
As a first step I printed out the signal handled at the very start of Java_com_pi4j_library_pigpio_internal_PIGPIO_gpioInitialise to see what it was life before gpioInitialise is called. It looks like quite a lot. Then I looked at the code in pigpio and found something very interesting. There is actually a compile-time #define, EMBEDDED_IN_VM, which explicitly turns off pigpio's use of signals! Furthermore, there is a run-time flag as well. The code looks like: #ifndef EMBEDDED_IN_VM So, we can avoid the entire problem and use the OS-supplied pigpio by setting that flag! This looks like the footprints of someone being here before. I'm going to guess that it's Python. Now all we have to do is to figure out how to set that flag. |
Brace yourselves. Here's the fix (I hope). In the native C bindings we have the function Immediately before that insert I can't actually test this as I can't build an armv6 native library right now, but I strongly believe it should work. |
…ignals and preventing signals from reaching the JVM.
Here is the compiled JAR with the changes you suggested if you would like to test it out: |
While applying the fix you suggested, I also came across these lines of code: It looks like I was originally registering signal handlers with PiGPIO to try and capture exit/terminate signals and then terminate the PiGPIO library as well as terminate the JVM application with |
FIX: Issue #15; Prevent the PiGPIO library from internally handling s…
REOPENING only to address the question above (#15 (comment)) about getting rid of Java-side signal handlers registered with PiGPIO. I suspect these can be removed now? Especially if the change @hackerjimbo suggested completely disables signals in PiGPIO. |
@savageautomate Those signal handlers can now never be called as we no longer intercept the signals with PiGPIO. Hopefully :-) Note that the signals aren't disabled, they're just handled by the JVM. Hopefully the JVM shutdown code should call the handler you registered. Actually, I just tried a control-c on a running program. I got the following series of errors:
|
… from Pi4J Java code. We now disable signals in PiGPIO and no longer need to register for callbacks to shutdown gracefully.
Removed these signal callbacks and deployed update SNAPSHOT JARs. |
…ng signals and preventing signals from reaching the JVM.
…acks from Pi4J Java code. We now disable signals in PiGPIO and no longer need to register for callbacks to shutdown gracefully.
As reported by Jim Darby:
If you're running as root (never a good idea) and using pigpio directly then pigpio steals all the signal handlers. The JVM doesn't like this as it uses them in running the JVM so it ends up with the program crashing. I'm working on this by getting pi4j-v2 to put back the signal handlers that the JVM uses.
The text was updated successfully, but these errors were encountered: