Author vstinner
Recipients bkabrda, neologix, njs, vstinner
Date 2017-03-22.08:29:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1490171388.53.0.013083295099.issue21895@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2017-03-22 08:29:48vstinnersetrecipients: + vstinner, njs, neologix, bkabrda
2017-03-22 08:29:48vstinnersetmessageid: <1490171388.53.0.013083295099.issue21895@psf.upfronthosting.co.za>
2017-03-22 08:29:48vstinnerlinkissue21895 messages
2017-03-22 08:29:47vstinnercreate