STINNER Victor added the comment: Attached signal_pause_doesnt_wake_up.py is a little bit complex and not sure that it's reliable.
I wrote thread_signal.py which should have a more deterministic behaviour. Output on Linux: --- main: main thread 140392674538560 thread: wait main: spawn thread 140392542746368 main: sleep main: send signal to thread main: sleep again Python signal handler, thread 140392674538560 main: wait thread thread: done main: done --- As expected, the Python signal handler is called in the main thread. time.sleep() in the thread *is* interrupted by SIGUSR1 (select() fails with EINTR), but PyErr_CheckSignals() does nothing since it's not the main thread. Then the sleep is automatically restarted (PEP 475). The code works as expected, but I understand that the behaviour is surprising. To be honest, I never understood the rationale behind "only execute signal handlers in the main thread". I was also surprised to no see a pthread_kill() in the C signal handler. I dislike the idea of transfering the signal to the main thread from another thread in the C signal handler using pthread_kill(). Most code behave very badly when getting a signal, so getting a signal twice is likely to double the pain. Moreover, pthread_sigmask() can block signals in the main thread for deliberate reasons. If we should change something, I simply suggest to remove the arbitrary limitation from the C signal handler. I don't know the consequences yet. ---------- Added file: http://bugs.python.org/file46752/thread_signal.py _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21895> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
