No, nothing that abstract. Using WSGI forces a new thread for each request. This is is a simple and inefficient brute force approach that really only suits the simplest Python applications and where only a small number of concurrent connection might be expected.
Any application that provides web services is going to OS block on file reading (and writing) and on database access. Using threads is a classic and easy way out that carries a lot of baggage. Windows has had a way out of this for years with its asynch (or event) notification set up through an OVERLAPPED structure. Lightttpd makes use of efficient event notification schemes like kqueue and epoll. Apache only uses such schemes for listening and Keep- Alives. No matter how careful one is with threads and processes there always appears to be unexpected gotchas. Python has a notorious example, the now fixed 'Beazly Effect' that affected the GIL. Also I don't think there is a single experienced Python user that trusts the GIL. John Heenan On Aug 25, 12:40 pm, pierreth <[email protected]> wrote: > I don't understand. The link is broken at the moment. > > Do you mean using only on thread and dispatching using the observer > pattern? Doing only one request at a time? It does not makes sense to > me. But I guess there is something I don't understand... Can someone > guide me? > > On 24 août, 20:04, mdipierro <[email protected]> wrote: > > > I agree with you. web2py does not care. It is the web server that > > decides. The question that started this thread was about the built-in > > web server and it does follow the thread model. > > > On Aug 24, 2:00 pm, John Heenan <[email protected]> wrote: > > > > Can't we at least have an acknowledgement that it is not necessary for > > > web2py to use a thread per request model and that web2py could instead > > > use an event model?
