Repository navigation
problem with siginterrupt #56433
Description
| BPO | 12224 |
|---|---|
| Nosy | @terryjreedy, @vstinner |
| Files |
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:
assignee = None
closed_at = <Date 2011-06-04.11:28:39.404>
created_at = <Date 2011-05-31.11:23:34.181>
labels = ['type-bug', 'library']
title = 'problem with siginterrupt'
updated_at = <Date 2011-06-04.13:12:38.221>
user = 'https://bugs.python.org/ZhipingDeng'bugs.python.org fields:
activity = <Date 2011-06-04.13:12:38.221>
actor = 'Zhiping.Deng'
assignee = 'none'
closed = True
closed_date = <Date 2011-06-04.11:28:39.404>
closer = 'vstinner'
components = ['Library (Lib)']
creation = <Date 2011-05-31.11:23:34.181>
creator = 'Zhiping.Deng'
dependencies = []
files = ['22207']
hgrepos = []
issue_num = 12224
keywords = []
message_count = 6.0
messages = ['137357', '137360', '137611', '137631', '137634', '137637']
nosy_count = 4.0
nosy_names = ['terry.reedy', 'vstinner', 'neologix', 'Zhiping.Deng']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue12224'
versions = ['Python 2.7']
Activity
ZhipingDeng commentedon May 31, 2011
If socket timeout > 0, then there is no way to automatically
restart some socket calls like recv().
Calling siginterrupt(False) is useless, because python calls
internal_select() if socket has timeout, and select returns
error(EINTR) once interrupted by a signal, regardless of the
SA_RESTART flags.
So a user may have to wrap every socket calls in this case.
I found some related discussions in http://bugs.python.org/issue7978
vstinner commentedon May 31, 2011
Extract of manpage signal(7):
"The following interfaces are never restarted after being interrupted by a signal handler, regardless of the use of SA_RESTART; they always fail with the error EINTR when interrupted by a signal handler:
Consider siginterrupt(signal, False) as a "best-effort" trick... which doesn't work with select().
If you don't want select() to be interrupted by SIGINT, use:
pthread_sigmask(SIG_BLOCK, [SIGINT]);
select(...)
pthread_sigmask(SIG_UNBLOCK, [SIGINT])
or
pselect() is atomic, whereas pthread_sigmask+select is not.
I added recently pthread_sigmask() to the signal module in Python 3.3.
pselect() is not exposed in Python currently. We may add it if it's needed.
--
If you really don't care of SIGINT, you can also ignore it completly using signal(SIGINT, SIG_IGN).
terryjreedy commentedon Jun 3, 2011
Victor, I understand your response as saying that there is no bug, which would suggest closing this. Correct? If not, what is the requested action?
neologix commentedon Jun 4, 2011
Actually, it's part of a more general problem with EINTR being returned by many posix/socket module functions, see for example issue bpo-7978.
On the one hand, having to retry manually on EINTR is cumbersome, on the other hand, some code might rely on this - receiving EINTR - and the posix module policy is to expose syscalls as-is.
This should probably be closed as duplicate of issue bpo-9867.
vstinner commentedon Jun 4, 2011
siginterrupt(False) has no effect on select().
I listed some solutions to not interrupt select() on a signal (avoid completly EINTR). Issues bpo-7978 and bpo-9867 try the other solution, handle EINTR (retry select() on EINTR). I think that most users prefer the later (handle EINTR), so let's close as a duplicate.
@zhiping Deng: Reopen the issue if you want the first solution :-)
ZhipingDeng commentedon Jun 4, 2011
I think the problem is that after a user calles signal.siginterrupt(False),
he would expect that the socket.recv should handles EINTR properly
for him because it's the behaviour in c level.
He doesn't know socket.recv() calles select(2) internally and he needn't.
Or at least this should be documented in signal.siginterrupt().