Issue 5785: Condition.wait() does not respect its timeout (original) (raw)

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#

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.