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!shaftesbury.zen.co.uk.POSTED!not-for-mail
From: Nobody <nobody@nowhere.com>
Subject: Re: connect SIGINT to custom interrupt handler
Date: Sun, 15 May 2011 14:08:59 +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.15.13.08.22.15000@nowhere.com>
Newsgroups: comp.lang.python
References: <slrnisv835.b74.chris@scheingraber.no-ip.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Lines: 25
Organization: Zen Internet
NNTP-Posting-Host: 76457d5b.news.zen.co.uk
X-Trace: DXC=13g_]JA>>Fe87S;[P`ZWfhnok4Z\<mH4ihDU:2=XKPkh37WFN[hV_KdQOMCU8L]ShgY5=I[K?T[df
X-Complaints-To: abuse@zen.co.uk
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:5435

On Sun, 15 May 2011 09:44:04 +0000, Christoph Scheingraber wrote:

> signal.signal(signal.SIGINT, interrupt_handler)

> This worked fine in some rare lucky cases, but most of the times, the
> module I am using (my university's seismology project) catches the SIGINT
> and quits:
> 
> select.error: (4, 'Interrupted system call')

After installing the signal handler, call:

	signal.siginterrupt(signal.SIGINT, False)

This will cause (most) interrupted system calls to be restarted after the
signal has been handled.

> How can I prevent the imported module's function from catching the
> interrupt signal?

It isn't catching the signal. Unless you enable restarting of system
calls, an interrupted system call will typically fail with EINTR. Python
typically reports failures via exceptions; failures due to EINTR aren't
handled differently.