def __exit__(self, exc_type, exc_val, exc_tb): if exc_val is not None and self._cancel_on_error: self.shutdown(wait=True, cancel_futures=True) else: self.shutdown(wait=True) return False ``` (I believe the above would have to be specified as an override for each of ThreadPoolExecutor and ProcessPoolExecutor if cancel_on_error were supplied as a parameter to the executor constructor. They both currently use the ``__exit__`` specified in the abstract Executor class, which wouldn't have access to cancel_on_error.) My previous consideration about waiting for user input of cancel_futures after the release of 3.9, before adding cancel_on_error to the constructor still applies to some degree though. If it directly uses executor.shutdown() with cancel_futures set to True, the maintenance would be rather minimal. But, it would potentially risk adding an underutilized parameter to the executor constructor (which contributes to feature bloat). |
> Hmm, it should be possible. Do you specifically mean cancelling the pending
> futures once a single one of the submitted functions raises an exception,
> or cancelling the pending futures when the Executor itself raises an
> exception (I.E. BrokenProcessPool)? I would assume the prior, since that
> seems more useful to me.
I was referring to any exception within the context manager of the executor, not the futures or just the executor's exceptions, something such as the following:
with ThreadPoolExecutor(cancel_on_error=True) as executor:
# Code here
raise Exception
Then if Executor.__exit__ detects an exception it would call shutdown with cancel_futures set to True.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OAMG4JUFK54FTAASHQG5WNAA7BU7KRS7/
Code of Conduct: http://python.org/psf/codeofconduct/