Asynchronous processing is more efficient -- surely not?

Chris Angelico rosuav at
Wed Apr 4 08:45:18 EDT 2018

On Wed, Apr 4, 2018 at 10:16 PM, Julien Salort <listes at> wrote:
> In this case, the script spends most of its time waiting for a frame to be
> available on the cameras, and the time interval to query the other device.
> The fetching and processing of the frames take negligible time. The library
> that I use is not asynchronous, but it was very easy to run_in_executor the
> C function that blocks until a frame is available on a given camera.
> Compared to a non-async version where I would have had to use that C
> function with some short timeout and iterate over all cameras, I think the
> async version is more efficient. The await will just be as long as it takes
> for the WaitFrame C function to run... When the C function ends, the
> asynchronous task resumes... There is no need to adjust some timeout by
> hand.

Can you give an example? Let's say we have a simple blocking C function:

int get_data() {
    return 42;

How do you use run_in_executor to turn this asynchronous, and how
would this compare to creating one thread for each camera? AIUI,
run_in_executor uses a thread pool under the surface, so all you're
doing is using threads via an asyncio interface. Comparing to a
timeout implementation is unfair; a threaded implementation is more


More information about the Python-list mailing list