a91f06bd-743d-4cae-b831-7277996fa63e
commented
16 years ago Hello,
This issue is actually a follow up of bpo-960406. The patch applied there brought in a problem at least under FreeBSD. The problem is extremely annoying so I made an effort to uncover the source of it.
Here is an example code that shows the problem:
some_time = 6000000 # seconds
class MyThread(Thread):
def run(self):
while (True):
time.sleep(some_time)
t = MyThread()
t.start()
while(True):
select.select(None, None, None, some_time)Start this script, then try to interrupt it by hitting Control-C. If you run this code under Linux you won't see any problem. But under FreeBSD the script won't stop until the timeout in main thread occurs or some activity takes place on descriptors passed to the select().
My investigation showed that the source of the problem is in that how signals are processed. FreeBSD processes signals in opposite order than Linux. For example suppose we have a program that starts one user thread and allows both main and user threads to receive signals. Under Linux the signal handler always fires up in context of the main thread, but under FreeBSD the signal handler runs in context of the user thread. POSIX doesn't state which behavior is correct so both behaviors should be assumed to be correct and Python should be aware of them both. Before the patch from 960406 the Python made effort to deny signal handling in user threads but the patch dropped this code and all threads are allowed to handle signals.
Let's return to the script. When running the script under Linux the select() call is the one that gets interrupted by the signal and this allows the script to shutdown quickly. But under FreeBSD the sleep() call is interrupted by the signal leaving the main thread to wait on select() until timeout.
The description of bpo-960406 states:
"This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it."
And yes it behaves exactly as described but this behavior is inconsistent between different OSes.
To make things predictable I've restored the code that ensures that signal handler will run in context of main thread only:
long PyThread_start_new_thread(void (func)(void *), void \arg) { ... + sigset_t set, oset; ... + sigfillset(&set); + SET_THREAD_SIGMASK(SIG_BLOCK, &set, &oset); pthread_create(...) + SET_THREAD_SIGMASK(SIG_SETMASK, &oset, NULL); ...
and this works perfectly for me under FreeBSD and Linux at least for my needs. It doesn't bring any visible changes to readline behavior either. I'm using the 2.5.1 version of Python. In attach you can find this patch against the trunk.
I'm not Python guru but let me try to display my vision of the situation.
As I understand, my change does nothing for applications written in pure Python and running under Linux (without user modules written in C and using special thread and signal handling). Signals under Linux have absolutely no chance to be caught from within user threads as Python doesn't provide any way to alter the signal mask and with the default signal mask the signals always arrive to the main thread. So explicit prohibition to handle signals from within user thread doesn't change anything. On the other hand this change ensures that under FreeBSD things go exactly like under Linux.
Of course this change can possibly break some C-written module that relies on signal handling in context of user thread (as the signal mask of the user thread must be modified explicitly now). But anyway this is how things are meant to work in order to be portable. So I'm considering this possibility as highly unlikely.
I suppose the Mac OS X is affected also as it's based on FreeBSD.
gvanrossum
3b1c5871-4fff-449a-b2cf-9991c772fecb
pitrou
8d8a8db7-faf5-4c09-a2a3-2697dbaf0735
284fb00b-bb6d-44f0-9212-8a0900514d44
8726d1eb-a365-45b6-b81d-c75988975e5a
83d2e70e-e599-4a04-b820-3814bbdb9bef
c1cd71cc-34b3-40e2-a35b-9a6cbed4f6ea
80ecb1b9-0667-42ca-b060-2ce0190f0e4a
79528080-9d85-4d18-8a2a-8b1f07640dd7
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields: ```python assignee = None closed_at =
created_at =
labels = ['interpreter-core', 'type-bug', 'docs']
title = 'signals not always delivered to main thread, since other threads have the signal unmasked'
updated_at =
user = 'https://bugs.python.org/bamby'
```
bugs.python.org fields:
```python
activity =
actor = 'neologix'
assignee = 'none'
closed = True
closed_date =
closer = 'neologix'
components = ['Documentation', 'Interpreter Core']
creation =
creator = 'bamby'
dependencies = []
files = ['9333', '20047']
hgrepos = []
issue_num = 1975
keywords = ['patch']
message_count = 43.0
messages = ['61870', '61960', '62038', '62044', '79780', '79783', '79801', '82868', '82878', '82914', '82918', '83107', '91070', '92328', '96377', '96379', '96380', '96386', '96388', '96390', '96391', '96393', '96395', '96396', '96397', '96406', '96415', '96428', '96429', '96433', '96444', '96445', '96446', '96447', '116940', '121863', '121927', '122137', '124007', '149903', '149904', '149909', '152693']
nosy_count = 16.0
nosy_names = ['georg.brandl', 'gregory.p.smith', 'exarkun', 'Rhamphoryncus', 'pitrou', 'vstinner', 'movement', 'flub', 'ross', 'bamby', 'laca', 'duncf', 'mstepnicki', 'nh2', 'neologix', 'BreamoreBoy']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue1975'
versions = ['Python 3.3']
```