classification
Title: Condition.wait() does not respect its timeout
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Kjir, benjamin.peterson
Priority: normal Keywords:

Created on 2009-04-18 13:53 by Kjir, last changed 2009-04-20 01:49 by benjamin.peterson. This issue is now closed.

Messages (3)
msg86118 - (view) Author: Stéphane (Kjir) Date: 2009-04-18 13:53
I have an issue with the wait() method of Condition which doesn't seem 
to respect the timeout it is given: I couldn't create a simple example 
to reproduce the bug, because if I try to do something small and simple 
everything works as expected, but in the actual code it doesn't work, 
so here's the link to the code:

http://github.com/Kjir/amsn2/blob/
bda6829d0c7d50a1cbf1188cdfa3789c4b7967c5/amsn2/gui/front_ends/curses/
contact_list.py

The most interesting function is the last one, where there is a wait 
with timeout of 1 second. If I have a look at the logs, after the 
initial download of the list there is nothing happening, while I'd 
expect to see a "check" cycle every second or so. If there is a 
notification arriving, the whole thing fires up and updates the contact 
list as expected, but the timeout itself doesn't work.

I don't know if there could be a problem with other modules, for 
instance gobject, but if there is then you should update the 
documentation to point out such incompatibilities.

If you could help me to create a simpler program to test this issue I 
would happy to provide you a test case, but I am out of ideas right now 
on how to narrow down the issue.

If you want to download the code and test it, here are the instructions:
git clone git://github.com/Kjir/amsn2.git
cd amsn2
git checkout -b curses_cl origin/curs_cl
python amsn2.py -f curses 2>> run.log
Log in with an msn account, tail -f run.log in another terminal to 
watch the logs

If you want to se what happens on a notify, one of your contacts should 
change status.

And here are a very brief explanation on how the code is called, if you 
need it:
the whole code is divided in basically three areas, core, protocol and 
gui. I am working on the gui side and the methods contactListUpdated, 
groupUpdated and contactUpdated are called by the core through a 
gobject signal.

My python version is 2.5.2 on gentoo amd64, use flags:
berkdb gdbm ipv6 ncurses readline ssl threads tk xml
-build -doc -elibc_uclibc -examples -sqlite -ucs2 -wininst

If you need anything else, just ask!

Oh and here's the link to the posts on comp.lang.python:
http://groups.google.com/group/comp.lang.python/browse_thread/
thread/7fc388c30304bf22#
msg86171 - (view) Author: Stéphane (Kjir) Date: 2009-04-19 14:22
Ok I fixed the issue thanks to the help from Piet van Oostrum: I didn't 
call gobject.threads_init(), so that gave the unexpected behaviour. It 
is certainly bad documentation on the gobject side, but you may 
consider adding some kind of warning on the threading documentation 
page, since I guess gobject is quite commonly used.
msg86187 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-04-20 01:49
I don't think we need warnings about third party libraries in our docs.
History
Date User Action Args
2009-04-20 01:49:19benjamin.petersonsetstatus: open -> closed

nosy: + benjamin.peterson
messages: + msg86187

resolution: not a bug
2009-04-19 14:22:03Kjirsetmessages: + msg86171
2009-04-18 13:53:47Kjircreate