Asynchronous processing is more efficient -- surely not?

Julien Salort listes at
Wed Apr 4 11:48:35 EDT 2018

Le 04/04/2018 à 14:45, Chris Angelico a écrit :

> Can you give an example? Let's say we have a simple blocking C function:
> int get_data() {
>      sleep(2);
>      return 42;
> }

I am not saying that I understand 100% and that this is the best way, 
but it works for me:

% cat get_data.c
#include <unistd.h>

int get_data() {
     return 42;

% clang -shared -o libgetdata.dylib get_data.c

% cat
import ctypes
import asyncio

mylib = ctypes.cdll.LoadLibrary('libgetdata.dylib')

loop = asyncio.get_event_loop()

async def get_data():
     result = await loop.run_in_executor(None, mylib.get_data)
     print('C function returned', result)
     return result

async def another_task():
     for i in range(5):
         await asyncio.sleep(1)

loop.run_until_complete(asyncio.gather(get_data(), another_task()))

% python
C function returned 42

> How do you use run_in_executor to turn this asynchronous, and how
> would this compare to creating one thread for each camera?
This is exactely like creating a thread. Except that I have to do so 
only for blocking calls and without having to bother myself with threads 
or thread pools.
> 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
> comparable.
It is just that it looks very simple to me. But I have never really done 
any asynchronous programming before. So, maybe using threads is just as 
simple, I don't know. What I find nice with asyncio is that it 
integrates easily with already written Python code, i.e. converting 
synchronous code to asynchronous code is relatively straightforward. 
Again, my problem is that it leads to code duplication. But that 
probably means that I should separate the logic into separate functions 



More information about the Python-list mailing list