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 ncoghlan
Recipients giampaolo.rodola, gvanrossum, ncoghlan, pitrou, r.david.murray, srkunze, vstinner, yselivanov
Date 2015-07-09.08:56:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
The problems with using concurrent.futures directly for running synchronous tasks in the background are:

1. You have to manage the lifecycle of the executor yourself, rather than letting asyncio do it for you
2. There's no easy process wide way to modify the size of the background task thread pool (or switch to using processes instead)
3. There's no easy way for background tasks themselves to use asynchronous IO

With the switch to "background_call" as the name, I'd modify the implementation to detect coroutines and schedule them as tasks rather than running them in the executor.

However, I think it's clear that the idea and its potential benefits are sufficiently unclear that making the case effectively may require a PEP. That's probably worth doing anyway in order to thrash out more precise semantics.
Date User Action Args
2015-07-09 08:57:01ncoghlansetrecipients: + ncoghlan, gvanrossum, pitrou, vstinner, giampaolo.rodola, r.david.murray, yselivanov, srkunze
2015-07-09 08:57:01ncoghlansetmessageid: <>
2015-07-09 08:57:01ncoghlanlinkissue24571 messages
2015-07-09 08:56:59ncoghlancreate