Coro::Channel - message queues
use Coro::Channel;
$q1 = new Coro::Channel <maxsize>;
$q1->put ("xxx");
print $q1->get;
die unless $q1->size;
A Coro::Channel is the equivalent of a unix pipe (and similar to amiga message ports): you can put things into it on one end and read things out of it from the other end. If the capacity of the Channel is maxed out writers will block. Both ends of a Channel can be read/written from by as many coroutines as you want concurrently.
Create a new channel with the given maximum size (practically unlimited
if maxsize is omitted). Giving a size of one gives you a traditional
channel, i.e. a queue that can store only a single element (which means
there will be no buffering, and put will wait until there is a
corresponding get call). To buffer one element you have to specify
2, and so on.
Put the given scalar into the queue.
Return the next element from the queue, waiting if necessary.
Shuts down the Channel by pushing a virtual end marker onto it: This
changes the behaviour of the Channel when it becomes or is empty to return
undef, almost as if infinitely many undef elements have been put
into the queue.
Specifically, this function wakes up any pending get calls and lets
them return undef, the same on future get calls. size will return
the real number of stored elements, though.
Another way to describe the behaviour is that get calls will not block
when the queue becomes empty but immediately return undef. This means
that calls to put will work normally and the data will be returned on
subsequent get calls.
This method is useful to signal the end of data to any consumers, quite
similar to an end of stream on e.g. a tcp socket: You have one or more
producers that put data into the Channel and one or more consumers who
get them. When all producers have finished producing data, a call to
shutdown signals this fact to any consumers.
Return the number of elements waiting to be consumed. Please note that:
if ($q->size) {
my $data = $q->get;
...
}
is not a race condition but instead works just fine.
Marc Lehmann <schmorp@schmorp.de> http://home.schmorp.de/