Ian Bicking wrote:
> Jim Fulton wrote:
>
>>> Right now all threading and generally concurrency is handled by the
>>> server. Since it *has* to be handled by the server,
>>
>>
>>
>> Why does it have to be handled by the server?
>
>
> Because most WSGI apps are blocking, so unless you want the s
Jim Fulton wrote:
>> Right now all threading and generally concurrency is handled by the
>> server. Since it *has* to be handled by the server,
>
>
> Why does it have to be handled by the server?
Because most WSGI apps are blocking, so unless you want the server to be
non-concurrent it has to
Ian Bicking wrote:
> Jim Fulton wrote:
...
>> Why do I want this? It appears that this would be needed to enable
>> middleware components that manage application threads. I can imagine
>> though that there aren't any existing servers that handle what I've
>> suggested correctly.
>>
>> I do think
At 03:29 PM 12/15/2005 -0500, James Y Knight wrote:
>I was led to believe this was a valid thing to do from the following
>wording:
> > (Note: the application must invoke the start_response() callable
> > before the iterable yields its first body string, so that the
> > server can send the headers
At 03:01 PM 12/15/2005 -0500, Jim Fulton wrote:
>I'm a bit unclear about the timing of the start_response call.
>I think this is because the PEP is unclear, but perhaps I missed
>something.
>
>It doesn't appear that the PEP says when the start_response callable
>must be called. It gives several ex
James Y Knight wrote:
> On Dec 15, 2005, at 3:01 PM, Jim Fulton wrote:
>
>> Normally an application will call the start_response callable when the
>> application is called or when the result iterator is constructed, as
>> shown in the first 2 examples. An application, or more commonly, a
>> middle
Ian Bicking wrote:
> Jim Fulton wrote:
>
>> Has anyone written any thread-management middleware components for WSGI?
>> Many web applications need to run application code in separate threads.
>> Often, the number of threads needs to be limited, either by throttling
>> the rate of thread creation,
On Dec 15, 2005, at 3:01 PM, Jim Fulton wrote:
> Normally an application will call the start_response callable when the
> application is called or when the result iterator is constructed, as
> shown in the first 2 examples. An application, or more commonly, a
> middleware component that provides it
Jim Fulton wrote:
> The PEP is unclear on this and should be clarified, IMO.
My experience in using implementations is many servers do not require
the read size argument (they don't give a TypeError), but they block
without it, or if you read past CONTENT_LENGTH. So it should probably
be requi
Jim Fulton wrote:
> Has anyone written any thread-management middleware components for WSGI?
> Many web applications need to run application code in separate threads.
> Often, the number of threads needs to be limited, either by throttling
> the rate of thread creation, or by dispatching requests t
Jim Fulton wrote:
> I'm a bit unclear about the timing of the start_response call.
> I think this is because the PEP is unclear, but perhaps I missed
> something.
>
> It doesn't appear that the PEP says when the start_response callable
> must be called. It gives several examples. In most, the cal
I'm a bit unclear about the timing of the start_response call.
I think this is because the PEP is unclear, but perhaps I missed
something.
It doesn't appear that the PEP says when the start_response callable
must be called. It gives several examples. In most, the callback is
called when the appli
Has anyone written any thread-management middleware components for WSGI?
Many web applications need to run application code in separate threads.
Often, the number of threads needs to be limited, either by throttling
the rate of thread creation, or by dispatching requests to a thread pool.
This is
The PEP is unclear on this and should be clarified, IMO.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
14 matches
Mail list logo