"Michael Lazzaro" <[EMAIL PROTECTED]> wrote > Similarly, then, I
would expect:
>
> sub foo(...) is threaded { ... yield() ... return() }
>
> foo(...args...)
>
> to start &foo as a new thread.
Perhaps we should fall back on the old message passing abstraction, where
messages can be either synchronous or asynchronous. When you send a synch
message, the sender waits for a reply. Messages can be sent to either
threads that already exsit, or might require a new thread to be created.
This is analagous to the difference between calling a CTOR and calling a
method on an existing object.
Under this abstraction, using a co-routine would be sending synchronous
messages to an existing thead (a yield is a synchronous message); and a
normal sub call would be sending a synchronous message to a new thread (perl
might optimize to not actually create the new thread). Any server may choose
to send its reply before it has actually completed its work: i.e. sending a
return value is not necessarily the same thing as leaving a sub. I've found
this particular concept very useful when modeling pipelines in hardware
(admitedly that's a somewhat niche application).
So the concepts would be:
* create a new execution context?
* send synch message (and therefore wait for a reply)
* send asynch message (possibly a reply to an earlier synch message)
* wait for a message (possibly a reply; possibly a new request) -- the reply
might itelf be a synch message that you're expected to reply to.
* halt (aka wait for finalize) -- the thread has nothing more to do.
* destroy execution context -- not needed if GCed.
Dave.
