I'm already concerned about the overhead of pack()ing an integer and a float prior to writing thru the tie() for every statement, so socket writes are not an acceptable solution for my purposes.

I hate to tell you this, but tieing isn't quick. In the case of MMF, around 2 to 3 times slower than writing to a socket.

#! perl -slw
use strict;
use Win32::MMF::Shareable;
use IO::Socket::INET;
use Benchmark qw[ cmpthese ];

our $DSIZE ||= 100;

my $mmf;
tie $mmf, 'Win32::MMF::Shareable', 'mmf',
{
    namespace => 'Win32MMFTest',
    size      => 10000,
    reuse     => 0
};

my $sock = IO::Socket::INET->new( 'localhost:54321' );
my $data = 'X' x $DSIZE;

cmpthese -1, {
    MMF => sub { $mmf = $data },
    TCP => sub { print $sock $data }
};

__END__
C:\test>MMF-IO-b -DSIZE=8
        Rate  MMF  TCP
MMF  28872/s   -- -77%
TCP 123636/s 328%   --

C:\test>MMF-IO-b -DSIZE=80
        Rate  MMF  TCP
MMF  27401/s   -- -73%
TCP 102909/s 276%   --

C:\test>MMF-IO-b -DSIZE=800
       Rate  MMF  TCP
MMF 28295/s   -- -67%
TCP 86245/s 205%   --
[download]

And that could probably be speeded up by playing with the buffer sizes and upping the priority of the read threads.

Not certain how you conclude "imposes very little overhead", but a socket write (local or not) + a printf for every Perl statement looks like a lot of overhead to me. Esp. if the problem thread is in a tight loop (altho the socket write will block eventually, so I guess that mitigates that issue)

Not sure why you think it would block? The other ends of each of those sockets are being service by a dedicated thread that reads a line and posts it to a queue. With 2 processes running 100 threads, there appears to be negligable slowdown on the app under test and each of those 100 200 threads is in a tight loop incrementing a variable and outputting it to the console.

But, I can see I am wasting your time with a NIH solution you do not want, so I'll stop.

I know Win32::MMF has issues (mostly because its trying to be too clever, and locking everything in sight). But it was the tool at hand for Win32...however, given its issues, it may be a wash and I'll end up writing a simple variant that just does the mmap() equivalent, sans tie()'s and locks. And, having worked on both socket and memory mgmt internals of a few OS's, I know that sockets have more overhead than a pure mmap() solution. The issue is that Win32::MMF adds a lot of extra baggage; remove the baggage, and I'd expect a mmf to be significantly faster, and much lower overhead, than sockets and thread queues; after all, its just writing to its memory.

"Not sure why you think it would block?"

My monitor application doesn't run all the time, only when its needed to see whats happening. So eventually, sockets are going to run out of kernel buffers, and they're going to block.

I'm going to ignore Win32 for now, get the Sys::Mmap version working, and then see what it would take to deconstruct Win32::MMF back down to a minimal mmap() implementation (and maybe do the same for Sys::Mmap if needed). Who knows, maybe I'll end up with a nicely OS agnostic mmap() package for Perl.