On Sep 4, 2019, at 12:37, Bar Harel <bzvi7...@gmail.com> wrote: > > 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.
Is that really true for asynchronous APIs that are explicitly queue-based? After all, it’s a bit wasteful—and a bit more complicated—to put a semaphore in front of a bounded queue instead of just using the queue bounds. (And the inefficiency may be even worse in Python, because of its relatively high function call overhead, if using the semaphore requires you to pass a lambda that calls the actual function and then signals, whereas otherwise you could just pass the function itself. But then this probably isn’t a problem very often—if your tasks are so short that an extra layer of function call hurts, they’re probably too short to use with an Executor anyway…) I suppose the question is whether Executor is a queue-based API, or whether that’s an implementation detail of the two concrete executors. On the one hand, the Java API that it’s based on is definitely not explicitly queue-based; there are a zillion different kinds of executors, and some of them don’t use pools at all. But the Python API only has two executors: a thread pool and a process pool, and I think most people know they’re based on queues even if we don’t explicitly guarantee that anywhere.
_______________________________________________ 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/AGHSB6UENOIDFJ27YSMSQZT4ONSWD3LT/ Code of Conduct: http://python.org/psf/codeofconduct/
