Update: Changed 'quit' to 'END' in the example.

Before benchmarking thought that 10k messages per second would be nice for being a pure Perl solution. Well, on the Windows platform it can depleat the inbox at a rate of 20k messages per second. On the Mac and Linux VM, reaching 50k per second is no problem. For that reason, will introduce MCE::Shared::Inbox with the next MCE::Shared release.

Disclaimer. Inbox may not be the best solution out there which is fine. What it will do is run reasonably well on multiple platforms including Windows and support threads and processes. Inbox itself does not construct any pipes / fifos, mutexes, or any temp files or directory. Instead it rides on MCE::Shared's parallel data channels. Basically, Inbox doesn't create nor consume additional resources at the OS level.

That said, I'm not worried if one were to spawn 400 workers in the future on a server having 400 logical cores and do inter-child-or-thread communication using Inbox. MCE::Shared provides a 12-channel barrier to safeguard the OS Kernel. The effect is preserving the fluid-like OS experience while running.

Running.

on unix: perl demo.pl | wc -l
windows: perl demo.pl > nul
[download]

The Foo::Inbox package is found here.

use strict;
use warnings;

use Foo::Inbox;
use MCE::Hobo;
use MCE::Shared;

use List::Util qw( shuffle );
use Time::HiRes qw( sleep time );

my $inbox = MCE::Shared->share( Foo::Inbox->new() );
my @names = shuffle qw/ Barny Betty Fred Wilma /;
my $start = time;

$| = 1;

sub foo {
  my $name  = shift;
  my $count = 0;

  # remove my name from the list
  @names = grep { $_ ne $name } shuffle @names;

  # send greeting
  $inbox->send($name, \@names, 'Hello');

  while ( 1 ) {
    if ( my ($from, $data) = $inbox->recv($name) ) {
      last if $data->[0] eq 'END';

      # display the message received
      printf "%-5s received %s from %s\n", $name, $data->[0], $from;

      # send greeting again
      $inbox->send($name, \@names, 'Hello') if $count < 4167;

      # eventually stop benchmarking
      last if ++$count == 12500;

      # don't delay, fetch next message
      next;
    }

    # timer delay if empty
    sleep 0.01;
  }
}

MCE::Hobo->create(\&foo, $_) for @names;
MCE::Hobo->waitall;

printf {*STDERR} "duration: %0.03f seconds\n", time - $start;
[download]

For long jobs, the timer delay is not likely a problem. Certainly not if batching. Later, may integrate signal handling for notification. But then, signal handling isn't reliable on the Windows platform. So am giving the hybrid approach a try by running at maximum performance for a busy Inbox and delay otherwise.

Regards, Mario