achrist at easystreet.com wrote:
Peter Hansen wrote:

Queue.Queue.get() ...

That looks good. But that needs a thread to block, right?
A generator manages to run without being a thread (at least
overtly). If we have the suck() statement, we also need
something that's the opposite of a generator (a Sucker?)
and something that's the opposite of an iterator (a Suckee?).
I'm starting to get an idea why this is completely not all
You're probably looking for "watcher" or "dispatcher" patterns (using
"pattern" loosely), i.e. something which is registered to respond to a
particular type of "event" and process the results only when the event
occurs. See Patrick 's pydispatcher project for a fairly good framework
on which to build such things.


In a more general sense, this is asynchronous programming, so at the
high-end you could check out Twisted Matrix, which is a network-oriented
asynchronous event system (pydispatcher is primarily an in-process system).
The main question this raises is "How lightweight are threads?"
Can I program with dozens or hundreds of python threads in a
program (for example under Windows) and not notice that this is
an inefficient or inept coding style?
Large numbers of threads tend to cause problems eventually unless you're
using micro-threads under Stackless Python. Since AFAIK, micro-threads
haven't been re-implemented in Stackless 3.0, massively-threading
approaches aren't likely to be a great approach just yet. As an aside,
micro-threading, particularly when combined with continuations, allows
for programming some of the most beautiful ways to deal with
asynchronous events I've ever seen.

That said, a few dozen, or even hundred threads may run quite nicely
under Windows. Tim could likely give a better estimate, but I seem to
recall him saying (way back when Stackless was 1.0) that Win95 could
handle a far higher thread-load than Linux (possibly a few thousand
threads?) I really wouldn't try running a few thousand threads on most
boxes, however, the OSes just aren't designed to handle it well.


Mike C. Fletcher
Designer, VR Plumber, Coder

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2022 Grokbase