Simple threaded web-server based on BaseHTTPServer?
Donn Cave
donn at u.washington.edu
Thu Jan 31 19:21:54 EST 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