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 josh.r
Recipients docs@python, giampaolo.rodola, josh.r, pitrou, rhettinger, serhiy.storchaka, vstinner
Date 2015-05-28.21:08:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1432847323.52.0.00979214743297.issue19270@psf.upfronthosting.co.za>
In-reply-to
Content
sched has been around for a long time, but it's been useless for so many purposes that it *should* handle (completely unsafe in threaded contexts until 3.3, still can't handle useful threaded scenarios today, e.g. scheduling tasks for short delays when draining the task queue, waiting on a task with a long delay, see #20126 ) that calling it acceptable is more about lack of available uses than acceptable design.

Saying "don't schedule two events for the same time and priority if expect to cancel either of them" is not a reasonable solution; the main reason to schedule two such events in that way would be to have the option to cancel one but not the other; as is, trying to cancel one will (pseudo-)randomly cancel either of them. I don't particularly care how it's fixed (though the proposed fix for #13451 seems like a good one), and the issue with changing event order isn't so important, but cancelling the wrong event is really bad.
History
Date User Action Args
2015-05-28 21:08:43josh.rsetrecipients: + josh.r, rhettinger, pitrou, vstinner, giampaolo.rodola, docs@python, serhiy.storchaka
2015-05-28 21:08:43josh.rsetmessageid: <1432847323.52.0.00979214743297.issue19270@psf.upfronthosting.co.za>
2015-05-28 21:08:43josh.rlinkissue19270 messages
2015-05-28 21:08:43josh.rcreate