[Web-SIG] Web Container Interface

[Ian Bicking]

Phillip J. Eby wrote:
> At 11:13 PM 1/28/04 -0600, Ian Bicking wrote:
> 
>> So what alternative do you propose for handling a shutdown?  The 
>> application *needs* to know about this.  I don't think I trust atexit 
>> (though I'm open to it if it really would work).  Also, if the 
>> application spawns threads that will simply block shutdown unless they 
>> can be told to stop.
> 
> What do you propose to use instead of atexit?

After some experimentation, atexit works better than I had thought.  Now 
I don't know we bother with explicit shutdown methods.  So I remove the 
suggestion for a shutdown method.

>> I'm not trying to be difficult, I'm just trying to envision how I 
>> would adapt Webware's gateway and application (AppServer and 
>> Application) to this interface.  I don't think of Webware as being 
>> particularly featureful, so I'm surprised other people haven't seen 
>> these problems either, unless there are solutions that I'm missing.
> 
> 
> Well, I'm so far having trouble understanding the specific things you're 
> trying to do, that aren't addressed by stdlib features.  I am still open 
> to addressing whatever they might be, I just want concrete use cases and 
> narrow solutions.  IOW, I'm YAGNI on widening the interface, and saying 
> "show me the use cases".

Sessions remain the use case I consider to be unresolved.  I think 
sessions should be possible to implement portable, without requiring 
configuration that specifies the gateway's process/concurrency model. 
(That doesn't rule out configuration, just that in the absence we should 
be able to pick the right implementation)

Probably all this requires is a way to indicate the process model.

>> Now I'm confused.  If it's a single process, and handles only one 
>> request, isn't that just broken?  I don't know of any example of such 
>> a server, since it wouldn't be able to handle concurrent requests.
> 
> Do you need concurrent requests for a single-user "webtop" application 
> that runs on your desktop?  The fact that the model has a limited usage 
> profile doesn't make it broken.  Perhaps somebody will also speak up in 
> favor of "multiprocess+multithread" model that I previously mentioned as 
> making my head hurt.

Okay, I suppose it can exist, though it's a rather obscure 
implementation.  I suppose there are debugging environments that require 
this form of execution.

>>> LRSP-single means only one thread.  LRSP-multi means multi-threaded.
>>> Asynchronousness actually implies LRSP-multi, because if you're doing 
>>> an asynchronous event loop the only way you can afford to call a 
>>> blocking 'runCGI()' is to do it in a thread.  Twisted and ZServer are 
>>> asynchronous LRSP-multi.
>>
>>
>> Okay.  This seems to mean that Twisted wouldn't use this interface 
>> internally, since they don't want to unnecessarily spawn a thread, and 
>> the interface doesn't seem to allow for a non-blocking API.
> 
> 
> Twisted has a builtin "thread pool" mechanism for this.  A WSGI 
> implementation for Twisted would simply call (IIRC):
> 
>     reactor.callInThread(service.runCGI, stdinWrapper, stdoutWrapper, 
> stderrWrapper, environ)
> 
> And threads would only be spawned up to the configured pool size.  If 
> there are more concurrent requests than allocated threads, the runCGI 
> call will be queued until an existing thread finishes.
> 
> ZServer has a similar mechanism, although I believe it's more "internal" 
> and less available for a third party to do.  Twisted is flexible enough 
> that a third party could roll their own Twisted-based WSGI gateway, if 
> the core developers aren't interested or want no part of it.  :)

Yes, my point was just that Twisted .rpy scripts and the like wouldn't 
fit into the model.  Or, they could, but it would be kind of silly, 
since you'd loose all the advantages of async, even if you ran under a 
Twisted gateway.  In contrast, many other systems could be composed into 
gateway and application without any real downside.

   Ian