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.