default handle-signals=yes

[cjdoris]

333 added the ability to set handle-signals. The default value is no, this issue is to address the suggestion of defaulting to yes.

[cjdoris]

It appears that neither setting is ideal, but the current default (no) is less intrusive to non-Julia Python code.

Here is a Python session with the default (no), where I pressed Ctrl-C after each sleep:

PS>python -X juliacall-handle-signals=no
>>> import juliacall, time
>>> juliacall.Base.sleep(10)
...
KeyboardInterrupt
>>> juliacall.Base.seval("sleep(10)")
...
KeyboardInterrupt
>>> time.sleep(10)
...
KeyboardInterrupt
>>> 

In all cases, a KeyboardInterrupt was raised and it returned to the prompt. In the second case (seval), the exception was raised after 10 seconds (i.e. after the Julia code finished) whereas the other two cases raised immediately as desired.

Here are some sessions with the proposed yes:

PS>python -X juliacall-handle-signals=yes
>>> import juliacall, time
>>> juliacall.Base.sleep(10)
PS>python -X juliacall-handle-signals=yes
>>> import juliacall, time
>>> juliacall.Base.seval("sleep(10)")
Traceback (most recent call last):
PS>python -X juliacall-handle-signals=yes
>>> import juliacall, time
>>> time.sleep(10)
PS>

In all cases, pressing Ctrl-C immediately kills the Python process. This is especially undesireable in the case of time.sleep(10) which doesn't even call into Julia. Hence merely importing JuliaCall can cause unrelated code to behave differently - and there is probably code out there which relies heavily on KeyboardInterrupt to be raised.

These experiments were done on Windows, suggesting that on Windows at least, we keep the current default.

I don't know how other OSes behave yet - *nix has different signal mechanisms.

[dpinol]

Anybody has a temporary workaround for this?