[Python-ideas] Restartable Threads

[Josiah Carlson]

My 2 cents from my 30 seconds of reading this email thread:
encapsulation shouldn't be done on the thread level, it should be done
on the object level.  Create an object that offers the behavior you
want to have (call it ThreadStarter or something), and give it a
'start_thread()' method that returns a thread handle from which you
can .join() as necessary.  This ThreadStarter object keeps references
to the necessary structures that you need to pass to the lower level
threads.  Or heck, this ThreadStarter could handle the .join()
dispatch, etc.  If you think about it for 5 minutes, I'm sure you
could implement it.

Also, while it isn't impossible to "restart threads" the way you
conceive of it, your way of conceiving of the "restart" is
fundamentally wrong.  Can you restart a process whose stack you've
thrown away?  Of course not.  You've thrown away the process/thread's
stack (which can be seen by the fact that you can .join() the thread),
so you aren't "restarting" the thread, you are creating a new thread
with a new stack with some of the same arguments to called functions.

 - Josiah

(this message does not mean that I'm going to be spending much time in
this list anymore, just that I saw this silly idea and had to comment)

On Sun, Mar 2, 2008 at 3:16 PM, Gabriel Grant <grantgm at mcmaster.ca> wrote:
> 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
>
>
> _______________________________________________
>  Python-ideas mailing list
>  Python-ideas at python.org
>  http://mail.python.org/mailman/listinfo/python-ideas
>