You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in capnproto/capnproto#1542, Pycapnp is having issues with catching signals while executing long-running capnp C++ code, because Python's signal handlers are only executed outside of external code.
Other libraries also seem to have this issue, hence the existence of cysignals. I propose that any possibly-long-running C++ code (particularly blocking C++ code) is wrapped in
from cysignals.signals cimport sig_on, sig_off
sig_on()
try:
# C++ code
finally:
sig_off()
The text was updated successfully, but these errors were encountered:
Unfortunately I don't think this is so simple. sig_on() apparently uses setjmp() and then the signal handler longjmp()s back to it. This only really works if the C++ code has not done any RAII initialization before the longjmp(). Otherwise, all the necessary cleanup will be skipped. This would lead to a lot of problems when calling into Cap'n Proto / KJ code.
As described in capnproto/capnproto#1542, Pycapnp is having issues with catching signals while executing long-running capnp C++ code, because Python's signal handlers are only executed outside of external code.
Other libraries also seem to have this issue, hence the existence of
cysignals
. I propose that any possibly-long-running C++ code (particularly blocking C++ code) is wrapped inThe text was updated successfully, but these errors were encountered: