The Concurrency Model Debate

Ian Bicking writes on The Concurrency Model Debate.

My take is still simple (I think). The Python community needs to get it's act together so that there is something that hosting companies can provide that (nearly) all the frameworks can provide. We have too many options which pretty much means each framework needs to be explicitly supported by the hosting company.

I still believe that wsgi is critical to solving this for everything apart from Twisted applications (Twisted may be able to host wsgi applications but a twisted application cannot be hosted on a wsgi server).

Please, please can we focus on getting good wsgi servers for a) cgi (probably ok) b) worker threads c) worker processes. Once we have those then any wsgi framework gets all the hosting options available. We can get the scaling from the cheapest providers who can offer cgi only up through worker threads to worker processes and all without changing the application.

This would be an immediate advantage over Ruby and PHP which do not offer this flexibility (yet?).

Comments

[Ian Bicking]

FWIW, Python is in the same state as Perl, Ruby, and Java. mod_php is the exception, in that it provides a long-running process that is also somewhat isolated. All of them (well, except for Java) have a variety of deployment methods that include CGI, mod_*, and forking (and sometimes threaded), including Python (even excluding WSGI). In most cases these deployments options are per-framework, and this is what WSGI tries to resolve for Python.

Not that I don't want to fix this too, but we're not worse off than anyone else.

[DaveW]

Ian,

My take is that at the cheaper levels of hosting (ie those without root access) you get mod_php and mod_perl but for ruby and python you get only cgi.

What I want to see is support for wsgi in these lower hosting plans. To get that we will need the range of wsgi servers and most frameworks to support wsgi so that hosting companies can simply provide something that opens up lots of python options.