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 jinty
Recipients gvanrossum, jinty, r.david.murray, vstinner, yselivanov
Date 2015-10-30.09:27:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20151030092700.GA47689@Admins-MacBook-Air.local>
In-reply-to <CAP7+vJJe_HgLCPFb9UiMsdzXL6SA8naKdWKMc-9ASy-M9QHJkQ@mail.gmail.com>
Content
On Wed, Oct 28, 2015 at 03:32:36PM +0000, Guido van Rossum wrote:
> 
> Guido van Rossum added the comment:
> 
> How about we extend loop.stop() so that you can pass it an exception to
> raise once the loop is stopped? This exception would then be thrown out of
> run_forever(). There may be some delay (callbacks already scheduled will
> run first) but it is how things were meant to be.

It is better than the current situation where to call loop.stop() and
have the correct exit code I would need to resort to a global variable.

I would then probably try to write an exception handler like this:

    def exception_handler(loop, context):
        loop.stop(context.get('exception', Exception('unknown error')))

And then hope I don't lose the traceback!

> FWIW this isn't really enough to ensure cleanup happens before destructors
> run -- when the loop exits, tasks may still be active unless you keep track
> of all of them and explicitly cancel them (and run the loop until they have
> processed the cancellation).

At least in my situation I don't think this is a problem, the objective
is to shut down the process quickly to prevent bad things happening.
History
Date User Action Args
2015-10-30 09:27:04jintysetrecipients: + jinty, gvanrossum, vstinner, r.david.murray, yselivanov
2015-10-30 09:27:04jintylinkissue25489 messages
2015-10-30 09:27:03jintycreate