multiprocessing.Event.wait(n) doesn't time out properly

[mokrates]

BPO	12539

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2011-07-12.13:38:20.901>
created_at = <Date 2011-07-11.23:06:22.163>
labels = ['type-bug', 'invalid']
title = "multiprocessing.Event.wait(n) doesn't time out properly"
updated_at = <Date 2011-07-12.13:38:20.900>
user = 'https://bugs.python.org/mokrates'

bugs.python.org fields:

activity = <Date 2011-07-12.13:38:20.900>
actor = 'neologix'
assignee = 'none'
closed = True
closed_date = <Date 2011-07-12.13:38:20.901>
closer = 'neologix'
components = []
creation = <Date 2011-07-11.23:06:22.163>
creator = 'mokrates'
dependencies = []
files = []
hgrepos = []
issue_num = 12539
keywords = []
message_count = 4.0
messages = ['140165', '140174', '140178', '140185']
nosy_count = 2.0
nosy_names = ['neologix', 'mokrates']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue12539'
versions = ['Python 2.7']

[mokrates]

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

[neologix]

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)?

[mokrates]

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

[neologix]

> Are you using a 2.6.38 kernel?

Yes

Alright, closing as invalid then.