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.