Simple threaded web-server based on BaseHTTPServer?

Donn Cave donn at u.washington.edu
Fri Feb 1 01:21:54 CET 2002


Quoth Mark Hammond <mhammond at skippinet.com.au>:
| Paul Rubin wrote:
|> "Tim Peters" <tim.one at home.com> writes:
|>> Well, because there aren't "real threads" under the covers, a blocking
|>> operation in one uthread blocks *all* uthreads for the duration.
|>> 
|>> It should be possible to combine uthreads w/ native threads, but the
|>> semantic model gets ever-harder to master the more gimmicks get tossed into
|>> the mix.
|>>
|> 
|> I think the best approach (if feasible) is designing the i/o library
|> to always avoid blocking operations.
|
| But this is a PITA for casual users.  If, for example, you had an IO 
| library where "read()" never blocked, then obviously all the code would 
| need to add support for some sort of notification when the read actually 
| completed and the data is available.  Even then, you would find most 
| programmers then simply issue the non-blocking read call, and 
| immediately wait for the completion notification - meaning you are in 
| the exact same position.
|
| Code written for non-blocking IO is often significantly different than 
| that written for blocking IO.

I wasn't sure what he meant by that, myself, but if I wanted to put words
in his mouth that I would agree with ... Ideally, library design might
use select() to dispatch the application.  This avoids blocking operations
the right way:  reads don't block, because they aren't posted until data
is ready.

As opposed to using threads for each I/O channel, and letting them block
until something arrives.

	Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list