On 6/20/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
"Charles Reiss" <[EMAIL PROTECTED]> wrote: > > Since I don't think the three-tiered threading system is going to be > implemented very soon, I'd like to propose that thread creation > instead be done with one new method of a ParrotThread object: > > =item C<thread_id = thread_object.'thread'(flags, subroutine, > arguments...)> > Maybe we should go for a name that's more descriptive of what's happening, such as "new_thread"?
I'd prefer 'run' myself.
However, I'm not too sure whether this is the best answer. Maybe it would be better to create a thread object for a thread that you intend to spawn, just as you instantiate any other PMC, perhaps with some flags and the sub being given as arguments to the constructor. Then perhaps use the invoke v-table methods, invoking it like a sub, to actually spawn the new thread. This way the thread object is around to call methods on to get its status, change its priority etc.
This would probably be a nice interface to provide for the common case. There is a question of how it will interact with thread destruction: either we will need a way to keep information about a thread around well after it is destroyed (even if as little as enough to reserve its thread ID) until we can be sure that references to its wrapper objects are gone or we will need to specify that rather unexpected behavior can happen when attempts are made to use the thread wrapper after the underlying thread has been detached or joined in another thread (this unexpected behavior including the operations affecting an unrelated thread). The latter behavior is certainly the easier to implement, but if we did, I'd be concerned about users not noticing the caveat, which is one reason why I was reluctant to propose not using numerical thread ids (which should at least suggest to users that they may be reused or become invalid). The greater intuitiveness is probably worth it, however. [snip] -- Charles
