了解asyncio：异步与同步回调

Question

There's one very particular thing about asyncio that I can't seem to understand. And that is the difference between asynchronous and synchronous callbacks. Let me introduce some examples.

Asyncio TCP example:

class EchoServer(asyncio.Protocol):

def connection_made(self, transport):
    print('connection made')

def data_received(self, data):
    print('data received: ', data.decode())

def eof_received(self):
    pass

def connection_lost(self, exc):
    print('connection lost:', exc)

Aiohttp example:

async def simple(request):
    return Response(text="Simple answer")

async def init(loop):
    app = Application(loop=loop)
    app.router.add_get('/simple', simple)
    return app

loop = asyncio.get_event_loop()
app = loop.run_until_complete(init(loop))
run_app(app, loop=loop)

Those two examples are very similar in functionality but they seem to be both doing it in different way. In the first example, if you want to be notified on some action, you specify a synchronous function ( EchoServer.connection_made ). However, in the second example, if you want to be notified on some action, you have to define an asynchronous callback function ( simple ).

I would like to ask what is the difference between these two types of callback. I understand the difference between regular functions and asynchronous functions, but I cannot wrap my head around the callback difference. For example, if I would want to write an asynchrnonous API like aiohttp is, and I would have a function that would do something and call a callback after that, how would I decide if I should demand an asynchronous function to be passed as an argument or just a regular synchronous one?

Answer 1

In aiohttp example you could do asynchronous calls from simple web-handler: access to database, make http requests etc.

In Protocol.data_received() you should call only regular synchronous methods.

UPD

Protocol callbacks are supposed to be synchronous by design. They are very low-level bridge between sync and async. You may call async code from them but it requires really tricky coding. User level asyncio API for sockets etc. are streams: https://docs.python.org/3/library/asyncio-stream.html

When you introduce your own callback system must likely you need asynchronous callback unless you are %100 sure why the callback will never want to call async code.

Regular functions ( def ) and coroutines ( async def ) have a different signatures. It's hard to change a required signature, especially if your code has published as a library and you cannot control all users of your callback.

PS

The same is true for any public API methods.

The hardest lesson I've learned during development of my libraries is: .close() method should be a coroutine even initially it calls sync functions only, eg socket.close() .

But later you perhaps will want to add a graceful shutdown which requires a waiting for current activity finishing and so on.

If your users had call your api as obj.close() now they should use await obj.close() but it's backward incompatible change!