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 gvanrossum
Recipients Justin Mayfield, gvanrossum, thehesiod, vstinner, yselivanov
Date 2015-11-12.17:42:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP7+vJ+bEO76=ZjHrB8-MZMq-FZ9pco8=L36Pw-oT83CeOiatw@mail.gmail.com>
In-reply-to <1447349123.76.0.244860398117.issue25593@psf.upfronthosting.co.za>
Content
Yeah, I've thought about changing the stop() mechanism too. It might
mean that some callbacks will be executed that are currently skipped
though, if your proposal is to run all callbacks in self._ready
(excluding new ones) and then just exit if the stop flag is set. I
worry about how this would violate expectations. We should be able to
get away with this, because PEP 3156 is carefully vague about exactly
how soon the loop will stop: it promises that callbacks scheduled
*before* stop() was called will run before the loop exist -- but it
makes no promises either way about callbacks schedule after stop() is
called.

A less intrusive change to stop() would be to somehow mark the point
in self._ready where stop is called, so stopping at the same point as
with the old algorithm, except for one difference: if you call stop()
multiple times, it currently leaves extra "markers" in self._ready,
which must be consumed by calling run_forever() multiple times. This
proposal would change the semantics of that case. Again, I don't think
PEP 3156 prevents us from doing that.

But I still think those callbacks should be fixed (Alexander's
original fix, extended to a few other callbacks that use
fut.cancelled()).
History
Date User Action Args
2015-11-12 17:42:02gvanrossumsetrecipients: + gvanrossum, vstinner, yselivanov, thehesiod, Justin Mayfield
2015-11-12 17:42:02gvanrossumlinkissue25593 messages
2015-11-12 17:42:02gvanrossumcreate