Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Subject: Re: threading.Condition.wait() is not catching SIGTERM
From: Sangeeth Saravanaraj <sangeeth.saravanaraj@gmail.com>
In-Reply-To: <nad-48DB8B.13135603072014@news.gmane.org>
Date: Fri, 4 Jul 2014 06:18:00 +0530
Content-Transfer-Encoding: quoted-printable
References: <17F05A1B-44C8-4F25-AFE9-5DBCFFB9982B@gmail.com> <nad-48DB8B.13135603072014@news.gmane.org>
To: Ned Deily <nad@acm.org>
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.11476.1404434892.18130.python-list@python.org>
Lines: 78
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:73929


On 04-Jul-2014, at 1:43 am, Ned Deily <nad@acm.org> wrote:

> In article <17F05A1B-44C8-4F25-AFE9-5DBCFFB9982B@gmail.com>,
>> I have the following code which when executed waits to be interrupted =
by=20
>> SIGINT, SIGTERM or SIGQUIT. When an object is initialized, it creates =
a=20
>> threading.Condition() and acquires() it! The program then registers =
the=20
>> signal handlers where notify() and release() is called when the above=20=

>> mentioned signals are received. After registering the signal =
handlers, it=20
>> calls wait() on the condition variable and block.
>>=20
>> When I tried to stop the program with Ctrl-C, its did not respond. =
IOW, the=20
>> _signal_handler() method did not get called. =20
>=20
> I'm not sure what you are trying to do but your test case seems =
flawed. =20
> threading.Condition is designed to be used with multiple threads but=20=

> your test doesn't actually use threads.  If you run your test with a=20=

> reasonably current Python 3 (after changing print to print()), you can=20=

> see that it fails (and why it fails) when interrupting with Ctrl-C:
>=20
> Waiting to be interrupted!
> ^CReceived terminate request - signal =3D 2
> Traceback (most recent call last):
>  File "b.py", line 30, in <module>
>    main()
>  File "b.py", line 27, in main
>    a.register_and_wait()
>  File "b.py", line 22, in register_and_wait
>    self._termination_signal.wait()      # control blocks here!
>  File=20
> =
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threadin
> g.py", line 289, in wait
>    waiter.acquire()
>  File "b.py", line 13, in _signal_handler
>    self._termination_signal.notify()
>  File=20
> =
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threadin
> g.py", line 339, in notify
>    raise RuntimeError("cannot notify on un-acquired lock")
> RuntimeError: cannot notify on un-acquired lock
>=20
> After a quick glance, I'm not sure why Python 2.7 is behaving=20
> differently, e.g. not raising an error, since both versions of=20
> Condition.notify have the same test so the difference is elsewhere. =20=

> Feel free to open an issue for not catching the error in 2.7 but you=20=


Ned, thanks for the explanation.=20

I have filed http://bugs.python.org/issue21913 to explore further on =
this issue.

Thank you,

Sangeeth=20

> should rethink what you are trying to do here.
>=20
> --=20
> Ned Deily,
> nad@acm.org
>=20
> --=20
> https://mail.python.org/mailman/listinfo/python-list