# Signal Handlers with Embedded Julia

**URL:** <https://discourse.julialang.org/t/signal-handlers-with-embedded-julia/41701>\
**Category:** Internals & Design\
**Tags:** embedding\
**Created:** [June 18, 2020, 9:57pm UTC](https://discourse.julialang.org/t/signal-handlers-with-embedded-julia/41701 "2020-06-18T21:57:36Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![SMShane](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@SMShane](https://discourse.julialang.org/u/SMShane)\
**Post date:** [June 18, 2020, 9:57pm UTC](https://discourse.julialang.org/t/signal-handlers-with-embedded-julia/41701/1 "2020-06-18T21:57:36Z")

</div>

We are embedding Julia in a larger software suite on Linux/MacOS/Windows.  
This existing software makes use of some signal handlers and where it doesn’t some users expect behaviours such as Ctrl-C to interrupt to work.  
When integrating Julia with jl\_init\_with\_image if I specify  
jl\_options.handle\_signals = JL\_OPTIONS\_HANDLE\_SIGNALS\_OFF;  
then this certainly on linux and windows seems to leave the signal handlers alone  
however when testing on MacOS the signal handlers get set to a SIG\_IGN value even though JL\_OPTIONS\_HANDLE\_SIGNALS\_OFF is selected and so no longer have an effect.  
Looking deeper it seems that the call to restore\_signals is causing this behaviour.  
Specifically both starting the signals\_thread and setting sigprocmask seem problematic.  
Also, as far as I can tell the linux manpage says that sigprocmask has undefined behaviour in a threaded process, which is intrinsically violated by the creation of the signals\_thread? [sigprocmask(2) - Linux manual page](https://www.man7.org/linux/man-pages/man2/sigprocmask.2.html)  
What is the intended behaviour?  
What is the utility of restore\_signals?  
Would it be possible/sensible to also only call this function?  
if (jl\_options.handle\_signals == JL\_OPTIONS\_HANDLE\_SIGNALS\_ON) {  
restore\_signals();  
}  
Thanks for any insight you can provide.