Following is my problem:
I have two processes, connected via multiprocessing.Event
The one waits for the other with .wait(300). After 300 seconds it should look if there's work, even if it has not been awoken by the other process.
So. This runs on my Laptop, and when I fold it shut, sending it to suspend, and open it again, lets say, 10 minutes later (which are 600 seconds), then the .wait()-timeout has already gone. I would assume, cause it's a /timeout/ that it should then fire ASAP, but it fires never. The worker process is just frozen and has to be awoken by .set()ing the Event.

I workarounded it by creating another thread, which uses time.sleep(300) instead of multiprocessing.Event.wait(300) to wait 300 seconds and some glue to put it all together.

some stats:
me@mybox:~$ python2.7
Python 2.7.1+ (default, Apr 20 2011, 22:33:39) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
me@mybox:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux testing (wheezy)
Release:	testing
Codename:	wheezy

Are you using a 2.6.38 kernel?
There was a regression in early 2.6.38 kernels that caused FUTEX_WAIT with a timeout to never return after a suspend-resume, see:
https://lkml.org/lkml/2011/4/13/23

It's been fixed by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0cd9c6494ee5c19aef085152bc37f3a4e774a9e1

Could you try with a more recent kernel (it should be fixed in 2.6.38.4)?

> Are you using a 2.6.38 kernel?

Yes

> There was a regression in early 2.6.38 kernels that caused FUTEX_WAIT
> with a timeout to never return after a suspend-resume, see:
> https://lkml.org/lkml/2011/4/13/23

Ah, thank you, that explains why gajim has problems too...

>  Could you try with a more recent kernel (it should be fixed in
> 2.6.38.4)?

I will, when it comes with my ubuntu... Thank you very much.

mo

>> Are you using a 2.6.38 kernel?

> Yes

Alright, closing as invalid then.