This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vilnis.termanis
Recipients vilnis.termanis
Date 2015-10-25.15:50:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1445788244.52.0.473500791521.issue25469@psf.upfronthosting.co.za>
In-reply-to
Content
A few additional notes:

1) On an AMD E-450 under Ubuntu 14.04 x64 with a current in-development build, when running condition_test.py, Condition.notify_all() takes (measure using time.clock) 0.0003 with the patch and 0.3219 without it. Additionally the in-script timeit calls seem to suggest that the patch does not adversely affect Condition.wait().

2) Unit tests have also been run against test_multiprocessing_forkserver (typo in original message).

3) A scenario where this might become apparent would be to have many worker processes which have a loop along the lines of:

while not event.is_set():
  do_more_work()
  # Pause because the task is only supposed to happen every X seconds
  # or a wait is in effect due to an error. Do not want to use
  # time.sleep so loop is exited promptly rather than blindly sleeping.
  event.wait(some_amount)
other_work_or_shutdown()

If many processes call event.wait() with a timeout and the event is not set often (e.g. since it's a shutdown flag), a long-running program with many worker processes can end up having event.set() take a considerable amount of time.
History
Date User Action Args
2015-10-25 15:50:44vilnis.termanissetrecipients: + vilnis.termanis
2015-10-25 15:50:44vilnis.termanissetmessageid: <1445788244.52.0.473500791521.issue25469@psf.upfronthosting.co.za>
2015-10-25 15:50:44vilnis.termanislinkissue25469 messages
2015-10-25 15:50:43vilnis.termaniscreate