[Web-SIG] Asynchronous architectures, abstract and concrete.

[Alan Kennedy]

[Phillip J. Eby]
 > [lots of excellent stuff snipped]

Thanks for the great explanations Phillip, and I agree with your 
positions on these issues.

There is just one area that I wanted to address.

[Alan Kennedy]
>> Welsh describes the use of thread-pools of a fixed "width" to service 
>> particular request types, with requests shunted between those 
>> (otherwise isolated) thread pools using queues.

[Phillip J. Eby]
> The description you use here sounds exactly like typical Python async 
> servers today: they have fixed-size threadpools for running 
> "application" code, and another fixed size thread pool (width=1) for I/O.

In reply

1. Welsh's architecture is much more abstract and high level, in that it 
discusses clustering, multiply redundant hardware pools, failover, 
isolation, load-balancing, etc, and no specific implementation technology.

2. The existing cpython frameworks are all still limited by the cpython 
GIL. Which gives all the more reason for pushing as much as possible 
down closer to the operating system, and outside of pure python.

3. Welsh's architecture discusses isolation of multiple IO subsystems 
into different thread groups. For example, there could be a thread group 
holding a pool of (blocking) database connections, which would be the 
appropriate "width" to process as many requests as can be concurrently 
supported by the RDBMS. Since there are blocking sockets/pipes/fifos 
between the application and the database, such database operations also 
count as a form of IO, which has to be managed. It could potentially be 
managed in an asynchronous fashion. Do any of the cpython frameworks 
support an asynchronous database API?

Just some thoughts.

I really think Welsh's paper is worth a read. In fact, it's been 6 
months since I read it: I'm going to read it now again, in light of my 
newly gained WSGI knowledge. Should only take 30 to 40 mins to read it 
again.

Regards,

Alan.