Brokes sb-ext:with-timeout

[VitoVan]

; SLIME 2.18
CL-USER> (defun test-timeout ()
(handler-case (sb-ext:with-timeout 2 (sleep 10))
(condition () "sb-ext:with-timeout works fine!")
(:no-error (r) (format nil "no timeout, result ~S" r))))
TEST-TIMEOUT
CL-USER> (test-timeout)
"sb-ext:with-timeout works fine!"
CL-USER> (ql:quickload 'burgled-batteries)
To load "burgled-batteries":
Load 1 ASDF system:
burgled-batteries
; Loading "burgled-batteries"
...
(BURGLED-BATTERIES)
CL-USER> (test-timeout)
"no timeout, result NIL"

[VitoVan]

It seems sb-ext:with-timeout is deprecated long long ago, but why this happened ?

[pinterface]

I suspect you're running into one of the problems with trying to shoehorn two different language runtimes into the same process: both SBCL and CPython have ideas on how to handle signals, and they compete with each other for who gets to handle it. There may be something that can be called on either the CPython side or the SBCL side to register/deregister signal handlers (my memory is a bit hazy, but I seem to recall needing to do something similar for floating-point traps), but I can't say for sure offhand.

[VitoVan]

Thank you, pinterface.

I think you're right, after burgled-batteries is loaded, the code below fails too:

(schedule-timer (make-timer (lambda ()
                              (write-line "Hello, world")
                              (force-output)))
                2)

Then I go checked the source of sbcl, finally found this:

https://github.com/sbcl/sbcl/blob/ae8b379b14f598907933228efca5c33ad3d66912/src/runtime/wrap.c#L569

It seems they use setitimer to perform schedule actions, then I checked man setitimer, found some signal related stuff.

But when I go through source code of burgled-batteries, I didn't find any fragments which 'register/deregister signal handlers'.

I am not familiar with C nor Common Lisp, is there any way to fix this?

[VitoVan]

I see, it's done by CPython or SBCL, not burgled-batteries, I mean 'register/deregister signal handlers'.

[pinterface]

Hrm... looks like it might be possible to change some or all of the `Py_Initialize()` calls (`(.initialize)`) to `Py_InitializeEx(0);` (`(.initialize-ex 0)`), which would skip registering signal handlers. That change is almost certainly safe within ffi-conditions.lisp. The calls inside api.lisp I'm less sure about--#'startup-python and #'call-with-python probably need to be adjusted to take a flag indicating whether to enable signal handling, so library users can choose whether the lisp side or the python side handles signals.

[VitoVan]

Thanks pinterface, I've checked the code and related docs, will give it a try.