> I must ask again about the actual necessity of adding a blocking call to
executor.submit in that particular case.
If I may intervene, the issue we're discussing about is frequently
encountered with asyncio: You can have an enormous queue of clients or
requests, creating a coroutine for each one of them, and using
asyncio.gather to finish them all.
Doing so would cause your memory to spike, and bad things to happen.
The way you solve it is with a semaphore mentioned earlier. It's a standard
mechanism, to be used in cases of asynchronous work, regardless of the
I believe adding a blocking submit, will create a different codebase, or
way of thinking, which depends on the underlying library, specifically
futures.concurrent in our case, and won't offer an advantage strong enough
to justify it.
As of now, you use the same constructs, no matter what kind of asynchronous
work you do. Why change it?