"Austin Hastings" <[EMAIL PROTECTED]> wrote
> --- Dave Whipp <[EMAIL PROTECTED]> wrote:
> > "Austin Hastings" <[EMAIL PROTECTED]> wrote:
> > > 1. C<yield> always acts the same way -- stores args in
> > CurThread.result
> > > and gives up control to [?something?].
> >
> > I think you want a fifo on the output there -- at least conceptually.
> > "Stores args in .result" might overly block the producer thread.
>
> Why would it "overly" block? If you say C<yield>, I assume you I<want>
> to block -- else, why not use a shared var?
The lack of a fifo requires the producer and consumer to run in lockstep (or
else you start losing data). The both ends of the channel have somewhat
bursty temporal behavior, then this coupling can be undesirable. A fifo, by
introducing slack, allows the system run more smoothly.
For a nicer interface, I would prefer that the fifo be implicit. This way,
the producer produces a sequences of scalars, and the consumer consumes
them; but if the "thread" is being executed as a coroutine, then perl can
omit the fifo as an optimization.
As an aside, C<yield> does not guarentee to block until the consumer has
consumed the current value: it just guarentees to give the scheduler the
option to switch contexts. So unless you know that your scheduler is
scheduling you as a coroutine, then the lack of a fifo (explicit or
implicit) would likely cause problems.
And why not use a shared variable? Because they are evil, the spawn of
Satan, etc. They are a breeding ground for bugs. Implicit fifos -- aka
message queues -- encapsulate the locks, and thus are not so bug-friendly.
Most importantly, a message queue abstraction works efficiently, though
differently, for both coroutines and threads. They let me describe the
dataflow independently of control flow.
> thread {
> loop {
> wait @x;
> print "X: ", @x.pop, "\n";
> }
> };
I hope we'll be able to write that as:
thread @x
{
print "X: ", @x.pop, "\n";
}
though it would be nice to make the C<pop> implicit:
thread <@x>
{
print "X: $_\n";
}
Dave
