[Chicago] Status of wsgi

[Carl Karsten]

Is this about it?

Client send a request, guessing there is some sort of ID?

Server starts processing the request, tells the client to check back soon.

Something starts processing the job

** Client checks back, gives the ID, server checks, tells the client
to try again later.
Loop a few times till  job is done,
result gets stored somewhere.

Client checks back, gives the ID, server checks, sees result for that
ID, passes it to the client.

All done.

Which means the server has to deal with the ** loop, but it only
causes a moment of resource hit, and so can deal with ... a million
little hits and not chew up resources?

Instead of allocating some recourses (memory?) for the duration of the
job.  Is there anything else involved in holding the connection open?
I guess something has to manage timeouts, but that seems trivial.

Then again all of this stuff is trivial.  theres just so much of it
that some trivials are better than others.


On Thu, Oct 11, 2012 at 1:30 PM, Japhy Bartlett <japhy at pearachute.com> wrote:
> When you're doing something like comet polling, "sitting around doing
> nothing" means blocking the client request until you have data to return,
> versus closing the connection and having the client repeatedly send
> requests.
>
> You're correct, it's mostly a resource optimization, but it can be
> significant if you're trying to handle lots of clients in real time.
>
> It was mentioned earlier in the thread, but tornado is a great example of
> WSGI and async living together in a single python webapp.
>
>
> On Thu, Oct 11, 2012 at 1:25 PM, Carl Karsten <carl at personnelware.com>
> wrote:
>>
>> On Wed, Oct 10, 2012 at 11:14 PM, Jordan Bettis <jordanb at hafd.org> wrote:
>> > But if there's no mechanism for setting the request aside, the the
>> > worker thread has to sit around doing nothing while the search server
>> > does its thing. An asynchronous framework would let the worker set the
>> > request aside and process new requests while it's waiting for the
>> > response from the search server.
>>
>> What is the difference between "sit around doing nothing" and "setting
>> the request aside"  ?
>>
>> I am guessing there is a resource (memory, connections, stack?) issue,
>> but I don't really see how either model is going to be much different,
>> so I must be missing something.
>>
>> --
>> Carl K
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org
>> http://mail.python.org/mailman/listinfo/chicago
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago
>



-- 
Carl K