threads only called once?

[Gerson Kurz]

On Wed, 7 Aug 2002 10:03:29 -0400, "Steve Holden"
<sholden at holdenweb.com> wrote:

>Reading and following the documentation is just too much trouble. Why
>doesn't Python do what I want?

That is a good question, because most of the time Python *does* do
what I want. Coincidence? Good Luck? Proof that free will doesn't
exist? You be the judge.

Anyway, this stuff was some weeks ago, so to refresh my memory I
looked at threading.py. I have found that I can think of two (2)
possible technical reasons, but - alas - I don't need either.

The class Thread has these members:

self.__target - function pointer (used for calling an arbitrary
function rather than a method)
self.__name - name of the thread. This is a generated name that
doesn't seem to reflect the OS-native Thread-ID in any way I can see.
self.__args - arguments passed to target function 
self.__kwargs  - keywords passed to target function 
self.__daemonic - "The significance of this flag is that the entire
Python program exits when only daemon threads are left."
self.__started - note if thread is active
self.__stopped - note if thread is stopped
self.__block - a "Condition" for thread joining (I suppose)
self.__initialized - just so that you know if __init__ has been
called.

ok, the supposed technical reason #1: the __name members should
reflect some kind of correlation with the OS-native thread. Duh, why
not use the OS-natives ID?

supposed technical reason #2: __daemonic (see above)

Now, as just happens I believe I know a bit about threading on both
Win32 and OS/2, and a lot less, but still infinitesimal more than
nothing, about linux pthreads. And from that I believe to know that,
if you save the "is running" state of a thread yourself and do not
rely on the OS to tell you if a thread is running or not, you're bound
to get it wrong. (which disposes of the __started and __stopped
variables). I could tell you mind boggling stories about OS/2 and
"zombie threads".[ However, to be fair, the code seems to provide for
timeouts waiting for threads to finish, which certainly is A GOOD
THING (TM).] Granted, since all these are beliefs, they could be
wrong.

... time.sleep(60) ...

After thinking more about that, I think the idea behind the Thread
object is just this: to represent an OS Thread. 

My reasoning was: The OS thread is just a function that has a separate
"thread of execution". (This is the case in Win32, in OS/2, in Posix).
Wrapping it in a class means, you want to provide "a baseclass" for
*tasks*. The "Thread" class just provides a standard way of defining
tasks (like: download data to a physical device, or handle incoming
V24 messages, or handle incoming socket connections) that, as a
side-feature, are run in their own thread. 

So, its really not a matter of not reading the documentation - I did
read it, but did not activate my language-lawyer-mode (I believe the
psychological buzzword is "anal-retentive") and thus failed to
recognize the grave implications of "at most once". I apologize.