[Python-bugs-list] [ python-Bugs-751260 ] Thread in threading.py can only be started once

[SourceForge.net]

Bugs item #751260, was opened at 2003-06-09 20:16
Message generated for change (Comment added) made by spiv
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751260&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Schuenzel (yahoo_alive)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread in threading.py can only be started once

Initial Comment:
class Thread doesn't reset self.__started after run() has terminated, so one cannot reuse 
the thread class and run start() again.


----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2003-06-15 22:35

Message:
Logged In: YES 
user_id=50945

> Imagine, you wish your thread to do some background work
> while normal execution goes on (e.g. parsing a website).
> It's a small task doing execatly the same job over an over.
> If that will happen often, the overhead of creating a new
> object might be too hight, especially if your object holds a
> lot of data. And sometime the garbage collector will kick
in...

Asking for this feature on the basis of performance sounds
bogus to me.  I'd expect creating and finishing threads to
be more expensive than the usual way to do this, which is to
have the one thread process chunks of work delivered via a
Queue.Queue (as opposed to creating a short-lived thread for
each chunk of work).

If you really think performance is the issue here, do some
benchmarking of the way things work at the moment versus
your proposal, versus long-lived threads using Queues.  If
you have some compelling numbers, then you'll have more
chance of convincing people this needs to be done.  (But my
guess is you'll find long-lived threads are more efficient.)


----------------------------------------------------------------------

Comment By: Lars Schuenzel (yahoo_alive)
Date: 2003-06-15 21:22

Message:
Logged In: YES 
user_id=647640

Maybe I should state some reasons for adding this functionality:

Imagine, you wish your thread to do some background work
while normal execution goes on (e.g. parsing a website).
It's a small task doing execatly the same job over an over.
If that will happen often, the overhead of creating a new
object might be too hight, especially if your object holds a
lot of data. And sometime the garbage collector will kick in...
If you want to write a really small class build from several
mix-in classes and Thread that only seldom needs to run
start(), you could use all member functions and variables.
Nice and neat.
And last but not least it wouldn't break compatibility.
Programs using threadying.py needn't change a single line.
There are more pro's and con's to this. To my opinion it is
more a matter of coding style and design. I do not know
Java's threads but I agree now with time_one: maybe this
issue is more a feature request than a bug report.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 13:56

Message:
Logged In: YES 
user_id=357491

I agree with Tim here.  I don't see a need for this anyway.  Once 
a thread has terminated it is done, period.  Having to 
reinstantiate a class to run another thread is perfectly 
reasonable.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-10 08:54

Message:
Logged In: YES 
user_id=31435

It's true that Thread instances can't be restarted, but you 
haven't made a case for calling that "a bug".  Python's 
threading model is fashioned loosely on Java's, and, like 
Java's, limits thread instances to one invocation by design.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751260&group_id=5470