Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #73929 > unrolled thread

Re: threading.Condition.wait() is not catching SIGTERM

Started bySangeeth Saravanaraj <sangeeth.saravanaraj@gmail.com>
First post2014-07-04 06:18 +0530
Last post2014-07-04 06:18 +0530
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: threading.Condition.wait() is not catching SIGTERM Sangeeth Saravanaraj <sangeeth.saravanaraj@gmail.com> - 2014-07-04 06:18 +0530

#73929 — Re: threading.Condition.wait() is not catching SIGTERM

FromSangeeth Saravanaraj <sangeeth.saravanaraj@gmail.com>
Date2014-07-04 06:18 +0530
SubjectRe: threading.Condition.wait() is not catching SIGTERM
Message-ID<mailman.11476.1404434892.18130.python-list@python.org>
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 
>> SIGINT, SIGTERM or SIGQUIT. When an object is initialized, it creates a 
>> threading.Condition() and acquires() it! The program then registers the 
>> signal handlers where notify() and release() is called when the above 
>> mentioned signals are received. After registering the signal handlers, it 
>> calls wait() on the condition variable and block.
>> 
>> When I tried to stop the program with Ctrl-C, its did not respond. IOW, the 
>> _signal_handler() method did not get called.  
> 
> I'm not sure what you are trying to do but your test case seems flawed.  
> threading.Condition is designed to be used with multiple threads but 
> your test doesn't actually use threads.  If you run your test with a 
> reasonably current Python 3 (after changing print to print()), you can 
> see that it fails (and why it fails) when interrupting with Ctrl-C:
> 
> Waiting to be interrupted!
> ^CReceived terminate request - signal = 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 
> "/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 
> "/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
> 
> After a quick glance, I'm not sure why Python 2.7 is behaving 
> differently, e.g. not raising an error, since both versions of 
> Condition.notify have the same test so the difference is elsewhere.  
> Feel free to open an issue for not catching the error in 2.7 but you 

Ned, thanks for the explanation. 

I have filed http://bugs.python.org/issue21913 to explore further on this issue.

Thank you,

Sangeeth 

> should rethink what you are trying to do here.
> 
> -- 
> Ned Deily,
> nad@acm.org
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web