Python threading?

[Steve Holden]

"Aahz" <aahz at pythoncraft.com> wrote ...
> In article <T5Rj9.13058$6g7.39977 at news-server.bigpond.net.au>,
> Mark Hammond  <mhammond at skippinet.com.au> wrote:
> >Aahz wrote:
> >> In article <f9Pi9.10275$Lg2.2191294 at news2.news.adelphia.net>,
> >> Robert Oschler <Oschler at earthlink.net> wrote:
> >>>
> >>>Also, what is a reasonable number of threads to expect to be able to
run
> >>>before context switching overhead becomes a problem (I'm using a PIII
500
> >>>Mhz with 512MB ram if that helps).
> >>
> >> It depends.  For pure Python-based computation, more than one thread
> >> will cost you more than you gain.  If it's almost pure I/O (file or
> >> socket stuff), you might be able to use as many as a couple of hundred
> >> threads.  Mostly, you're probably best off somewhere between five and
> >> thirty threads, depending on what you're doing.
> >
> >I would have thought that a brave call.  If you are performing lots of
> >IO and need many many connections, you are almost certainly better off
> >using an "asynchronous" approach, much like asyncore.  With a large
> >number of threads (where "large" can be as low as single figures) the OS
> >overhead of switching will be greater than your internal overhead of a
> >more complicated design.
>
> I've got no practical experience with asyncore, but I do with threads.
> While I accept the conventional wisdom that asyncore will frequently do
> better than threads for performance, I stand by my claims for what will
> work well with threads.
>
Until I read this, I thought there might be practical reasons to think about
mixing the two approaches. Asyncore is a great way to be responsive to
incoming network connections and data, but if the process then has to hang
around to do database I/O you might not win very much from the asynchronous
approach.

On the other hand, if the asynchronous handler starts a thread to handle its
task, then when the processing thread blocks the main asynchronous thread
can process further connections or inputs. Thus, I thought, there would be
benefits particularly when the requested tasks were likely to be relatively
lengthy.

> >A "one thread per connection" model is doomed from the start -
> >therefore, in most applications, I would consider 5 threads a large
> >number - particularly when all are actively doing something.  OTOH, if
> >you are willing to accept that your first version will accept a max of
> >~20 connections, the brain-power saved by using threads beats the
> >additional OS overhead by a mile ;)
>
> Overall, yes, but a lot of I/O is bursty, and with a number of blocked
> threads, up to a hundred or so can work well.  Note carefully that I
> *am* assuming a thread pool to avoid startup costs.

The thread pool obviously helps a great deal. I was sorry to see Mark
suggesting that "thread per connection" models won't be responsive, since
his word on that topic (especially for Windows) is likely to be
authoritative.

regards
-----------------------------------------------------------------------
Steve Holden                                  http://www.holdenweb.com/
Python Web Programming                 http://pydish.holdenweb.com/pwp/
Previous .sig file retired to                    www.homeforoldsigs.com
-----------------------------------------------------------------------