ANN: timeoutsocket.py --> v1.12 works with Python 2.0

[David Bolen]

Rick Lee <rwklee at home.com> writes:

> Thanks!  Sounds like select() is the way to go.  But, why not 1000 separate
> threads, just for argument's sake?

>From a purely functional design, no reason - if the system could
support that then it should function properly.  But from a resource
management perspective, threads are less efficient than other means.

Threads are lighter weight than processes, but they still require
resource from the system (since each must exist in some way within the
task scheduler of the OS) - uThreads in the stackless Python are
different and even lighter weight.  In the same way that you probably
wouldn't try to run your average system with hundreds of processes
(well at least large hundreds :-)), thousands of threads can begin to
strain things depending on your environment.

More importantly, in this type of common scenario (servicing I/O from
many connections), many systems have been tuned to permit efficient
wait mechanisms to discover which connection needs servicing, while
tying up a minimum of resource.  So largely it's just a more efficient
design, which becomes important when you're talking about such large
numbers.

It's not that one approach is always better than the other, as much as
they are both mechanisms in your "toolkit" - and can often be traded
off against each other during design or implementation.

In fact often the two mechanisms are interwoven.  The I/O handling
of any concurrent connection is handled by a main thread that is
waiting for requests from any client to be dispatched.  Once it gets
such a request completely from a single client, it then creates a
"worker" thread to process that request - letting it get back to
waiting for other requests.  In large systems, those worker threads
may be limited in number to help control overall load on the system,
and perhaps shared from a pool to avoid the creation/destruction
overhead of the thread.  Now, this can be more complicated code, but
can yield the best tradeoff in responsiveness and overhead.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/