frank at chagford.com
Tue Dec 13 08:15:55 EST 2016
I had a problem with asyncio - not a programming problem, but one with
organising my code to achieve a given result.
I have come up with a solution, but thought I would mention it here to see
if there is a better approach.
I am using asyncio.start_server() to run a simple HTTP server. Each request
is passed to a handler. I strive to complete each request as quickly as
possible, but I use 'await' where necessary to prevent blocking. It all
HTTP does not keep the connection open, it sends a message, waits for a
response, and closes the connection. In order to maintain 'state' for
concurrent users, I have a Session class, and each message contains a
session id so that I can pass the message to the correct session instance.
Again, it all works well.
The client uses AJAX to send messages to the server. It sends the message
and continues processing, while a background task waits for the response and
handles it appropriately. As a result, the client can send a second message
before receiving a response to the first one. The server can detect this,
but it cannot wait for the first message to complete, otherwise it will
block other clients. I have not noticed any problems with processing 2
requests from the same client concurrently, but I don't like it, so I want
to process them sequentially.
Here is my solution. As I create each Session instance, I set up a
background task, using asyncio.ensure_future, which sets up an
asyncio.Queue. The request handler identifies the session that the request
belongs to, and 'puts' the request onto that session's Queue. The background
task runs a 'while True' loop waiting for requests. As they come in it
'gets' them and processes them. It seems to work.
This means that I have a background task running for each concurrent user.
Each one will be idle most of the time. My gut-feel says that this will not
cause a problem, even if there are hundreds of them, but any comments will
More information about the Python-list