Message289977
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. |
|
Date |
User |
Action |
Args |
2017-03-22 08:29:48 | vstinner | set | recipients:
+ vstinner, njs, neologix, bkabrda |
2017-03-22 08:29:48 | vstinner | set | messageid: <1490171388.53.0.013083295099.issue21895@psf.upfronthosting.co.za> |
2017-03-22 08:29:48 | vstinner | link | issue21895 messages |
2017-03-22 08:29:47 | vstinner | create | |
|