Asyncio question

Frank Millman frank at chagford.com
Fri Feb 21 01:59:35 EST 2020


Hi all

I use asyncio in my project, and it works very well without my having to 
understand what goes on under the hood. It is a multi-user client/server 
system, and I want it to scale to many concurrent users. I have a 
situation where I have to decide between two approaches, and I want to 
choose the least resource-intensive, but I find it hard to reason about 
which, if either, is better.

I use HTTP. On the initial connection from a client, I set up a session 
object, and the session id is passed to the client. All subsequent 
requests from that client include the session id, and the request is 
passed to the session object for handling.

It is possible for a new request to be received from a client before the 
previous one has been completed, and I want each request to be handled 
atomically, so each session maintains its own asyncio.Queue(). The main 
routine gets the session id from the request and 'puts' the request in 
the appropriate queue. The session object 'gets' from the queue and 
handles the request. It works well.

The question is, how to arrange for each session to 'await' its queue. 
My first attempt was to create a background task for each session which 
runs for the life-time of the session, and 'awaits' its queue. It works, 
but I was concerned about having a lot a background tasks active at the 
same time.

Then I came up with what I thought was a better idea. On the initial 
connection, I create the session object, send the response to the 
client, and then 'await' the method that sets up the session's queue. 
This also works, and there is no background task involved. However, I 
then realised that the initial response handler never completes, and 
will 'await' until the session is closed.

Is this better, worse, or does it make no difference? If it makes no 
difference, I will lean towards the first approach, as it is easier to 
reason about what is going on.

Thanks for any advice.

Frank Millman



More information about the Python-list mailing list