> > 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 underlying library. 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? Sincerely, Bar Harel
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/BC2JPYIOJN3MPKECP5QLKKW4Y7UFWALJ/ Code of Conduct: http://python.org/psf/codeofconduct/
