[Python-ideas] Restartable Threads

Gabriel Grant grantgm at mcmaster.ca
Mon Mar 3 00:16:03 CET 2008


On Sun, Mar 2, 2008 at 5:11 PM, Leonardo Santagada <santagada at gmail.com> wrote:
> Sorry if I missed it from you email,
I know the message was a rather long. Sorry about that.

> but why cant you just create
>  another thread object before each start call?

The state of the thread needs to be preserved from start() to start()
because the C function needs to be passed the same object each time it
is called.

The state could be maintained by creating the persistent object in the
parent thread and passing it to a new child thread before each call,
but for a few reasons this feels wrong:

It seems to me that this would break encapsulation - objects exist for
the purpose of carrying state. They shouldn't rely on their parent to
do that for them.
Doing so would muck up the parent, especially once there are a)
multiple child threads and b) multiple state-carrying objects that
need to be maintained within each thread.

Also, from a more conceptual point of view, the C function basically
represents a single, restartable process, so it seems it should be
packaged and used as such. When the function returns, it is more akin
to a synchronization point between threads than stopping one and
creating then starting another.

Hopefully that clarifies my thinking a bit (or at least doesn't muddy
the waters any further :)

>  I think the only objection to restart a thread would be that the idea
>  is that each thread object represents a thread... but I might be
>  completely wrong.

And that may be a valid objection, although the lifetime of the Thread
object does not directly correspond with that of the thread it wraps.
The thread is created upon calling start(), and dies when run()
returns. The way it is implemented, the Thread object is more of a
thread creator and controller, than a physical thread. Otherwise, I
would think it should disapear after being join()ed. It seem to me
that these objects represent a more palatable abstraction of the
physical thread...but I might (also :) be completely wrong.

Given that we accept (enjoy, even?) some level of abstraction on top
of physical threads (for instance we start them after they have been
initialized, and we check whether they are running, not whether they
exist), it seems reasonable to me that stopping and restarting these
conceptual threads should be possible. What do you think?

Thanks again for your consideration,

-Gabriel



More information about the Python-ideas mailing list