Below is a proposal to change the syntax for creation of threads. The primary change is a move away from the original interface which had three thread-creation functions: thread1, thread2, and thread3. These were supposed to create threads in one of three types, see, e.g., Dan's proposal at http://www.nntp.perl.org/group/perl.perl6.internals/19876 The various types of threads were never really implemented. The only difference between them was that type-2 and type-3 threads would call clone_interpreter() [in parrotinterpreter.pmc] which, somewhat unexpectedly, only copied over the runops core choice and the interpreter flags -- presumably, it should be made to copy over more data in the future. Code would always be shared with the parent interpreter under the scheme.
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...)> Spawn a new thread. C<flags> is or'd together constants available from C<runtime/parrot/include/thread.pasm>. Now, only one constant is defined: =over 4 =item PARROT_THREAD_CLONE Specifies that the created thread shall call clone_interpreter() to 'clone' state from the parent thread into the child thread. =cut C<subroutine> is the subroutine to run in the new thread. The remaining arguments (any number is premitted) will be used as arguments to the subroutine. The arguments shall be cloned into the new interpreter unless they are shared PMCs. After this method returns, the ParrotThread PMC shall become Undef. [Rationale: ParrotThread inherits from ParrotInterpreter -- sensibly -- but manipulating the interpreter in a seperate thread is dangerous, especially since the interpreter shall be destroyed when the other thread is joined or exits after it is 'detached'. An obvious alternative is to morph the ParrotThread PMC into the thread ID which I think would be unexpectedly magical. The use of thread IDs instead of some 'thread handle' PMC represents no change from the original implementation. If we do create a core running-thread PMC type, it will probably end up just wrapping a thread ID and so its only advantage is likely to be the syntax with which thread-manipulating methods are called.] The returned thread ID may be used with various methods on the ParrotInterpreter object obtained by the getinterp opcode to manipulate the running thread. =cut Comments welcome. -- Charles Reiss
