This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: problem with siginterrupt
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.7
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: Zhiping.Deng, neologix, terry.reedy, vstinner
Priority: normal Keywords:

Created on 2011-05-31 11:23 by Zhiping.Deng, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit Zhiping.Deng, 2011-05-31 11:23
Messages (6)
msg137357 - (view) Author: Zhiping Deng (Zhiping.Deng) Date: 2011-05-31 11:23
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

So a user may have to wrap every socket calls in this case.

I found some related discussions in
msg137360 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-05-31 14:42
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:
 * ...
 * File descriptor multiplexing interfaces: epoll_wait(2), epoll_pwait(2), poll(2), ppoll(2), select(2), and pselect(2)."

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]);
pthread_sigmask(SIG_UNBLOCK, [SIGINT])


pselect(...., [SIGINT])

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).
msg137611 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-06-03 23:05
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?
msg137631 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-06-04 10:11
Actually, it's part of a more general problem with EINTR being returned by many posix/socket module functions, see for example issue #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 #9867.
msg137634 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-06-04 11:28
> 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?

siginterrupt(False) has no effect on select().

I listed some solutions to not interrupt select() on a signal (avoid completly EINTR). Issues #7978 and #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 :-)
msg137637 - (view) Author: Zhiping Deng (Zhiping.Deng) Date: 2011-06-04 13:12
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().
Date User Action Args
2022-04-11 14:57:18adminsetgithub: 56433
2011-06-04 13:12:38Zhiping.Dengsetmessages: + msg137637
2011-06-04 11:28:39vstinnersetstatus: open -> closed
resolution: duplicate
messages: + msg137634
2011-06-04 10:11:02neologixsetnosy: + neologix
messages: + msg137631
2011-06-03 23:05:31terry.reedysetnosy: + terry.reedy
messages: + msg137611
2011-05-31 14:42:53vstinnersetnosy: + vstinner
messages: + msg137360
2011-05-31 11:23:34Zhiping.Dengcreate