"Ian Kelly" wrote in message
news:CALwzid=vdczAH18mHKaL7ryvDUB=7_y-JVUrTkRZ=gkz66p...@mail.gmail.com...
On Tue, Dec 13, 2016 at 6:15 AM, Frank Millman <fr...@chagford.com> wrote:
> 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.
Is there a particular reason why you're worried about this? The
browser is perfectly capable of keeping the requests straight. Also,
note that since the requests use separate HTTP connections, even if
the server sends its responses in a particular order, there's no
guarantee that the client will read them in that order, so this
doesn't free you from the need to allow the client to handle the
requests coming back in any order.
I had not thought of that, thanks. In fact, more to the point in my case, I
assume that there is no guarantee that the server will receive the requests
in the same order that the client sends them.
The particular reason for my concern was that each request can change the
state of the session, and I wanted to be sure that the state has been fully
updated before processing the next request.
One scenario, that I had not thought of, is that the requests could be
received out of sequence. I don't think this will be a problem, but I will
have to think about it.
The second scenario, which was my main concern, is that the server starts
processing the second request before processing of the first request has
been completed, meaning that the session data may not be in a stable state.
My proposed solution solves this problem.
In a 64-bit Linux build of CPython, the combined size of a generator
and a stack frame is around half a kilobyte (not including whatever
space is needed for local variables), so hundreds of yielding asyncio
tasks should consume no more than hundreds of kilobytes of memory.
Remember that half a kilobyte figure is per generator, not per task,
so if your while loop is four coroutines deep, that will inflate the
cost of the task to two kilobytes each. This is different from the
threading model where each thread would need its own separate stack
space, not just a frame on the heap; you probably wouldn't want to do
this with threads, but with coroutines it should be fine.
Good to know, thanks. I will proceed on the assumption that if anyone runs
my system with hundreds of users, they will run it on some serious hardware,
so I should be safe.
Frank
--
https://mail.python.org/mailman/listinfo/python-list
