Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!feeds.phibee-telecom.net!dedekind.zen.co.uk!zen.net.uk!hamilton.zen.co.uk!reader02.news.zen.co.uk.POSTED!not-for-mail
From: Nobody <nobody@nowhere.com>
Subject: Re: connect SIGINT to custom interrupt handler
Date: Mon, 16 May 2011 03:53:22 +0100
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
Message-Id: <pan.2011.05.16.02.52.43.390000@nowhere.com>
Newsgroups: comp.lang.python
References: <slrnisv835.b74.chris@scheingraber.no-ip.org> <pan.2011.05.15.13.08.22.15000@nowhere.com> <slrnisvove.dj0.chris@scheingraber.no-ip.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Lines: 37
Organization: Zen Internet
NNTP-Posting-Host: fdb0db74.news.zen.co.uk
X-Trace: DXC=kGM8>PM7MiaR5C\68]hc6gYjZGX^207Pk`<MJMoM3PFm7eb9[IKohTbFJHPa[N739`=f=kfEGMnhhKnm1C7>@g5d
X-Complaints-To: abuse@zen.co.uk
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:5467

On Sun, 15 May 2011 14:32:13 +0000, Christoph Scheingraber wrote:

> I now have signal.siginterrupt(signal.SIGINT, False) in the line
> below signal.signal(signal.SIGINT, interrupt_handler)
> 
> Unfortunately, pressing ^c still results in the same interrupt error.

Sorry; I wasn't paying sufficient attention to the details:

>>> select.error: (4, 'Interrupted system call')

According to Linux' signal(7) manpage, select() is never restarted,
regardless of the siginterrupt() setting.

In general, wait-for-something functions aren't restarted; the caller is
expected to check that the waited-for condition actually happened, so
returning prematurely isn't considered problematic.

EINTR is one of those "special" errors (like EAGAIN) which don't
actually indicate an error. In the context of select(), a return value of
-1 with errno set to EINTR should normally be handled in the same way as a
return value of zero, i.e. "nothing has happened yet, try again".

While the EINTR case isn't identical to the zero-return case, it's much
closer to it than it is to a genuine error. If it's being treated like
genuine errors (i.e. raising an exception), that's a defect in the Python
bindings. In which case, I'd suggest catching the exception and checking
the error code, e.g.:

def myselect(rlist, wlist, xlist, timeout = None):
    try:
        return select.select(rlist, wlist, xlist, timeout)
    except select.error, e:
        if e[0] == errno.EINTR:
            return 0
        raise