Making no attempt to speak for the author, my first reaction is why are you trying to use memory mapped files to share data between threads?

All the threads of a process already have access to all the memory in that process. MMF is designed to allow processes to share memory, not threads.

I'm not going to say outright that this cannot be made to work, but the idea of attempting to mix ithreads; perl's own very special brand of shared data (threads::shareable); and a Perl tied interface to an OS IPC (InterProcessCommunication) mechanism; all within a single process just looks like a recipe for disaster to me.

In the normal model of things, MMF allows two processes to request that the OS map a single block of physical memory into the virtual address space of two separate processes--often at different virtual addresses. I've been trying to imagine what the OS is going to do if two threads ask the OS to map a single block of physical address space into the virtual address space of a single process twice?

• Will it recognise that the second request is a duplicate and return a handle to the same virtual address mapping?
• Or will it create a second mapping, effectively causing the same physical block of memory to appear in two places in the processes virtual memory map?
• And given that (Perlish) shared memory is already tied, what is going to be the effect of creating ties in two threads (which involves Perlish data structures that are only useable within the ithreads in which they are created), to the "same" piece of memory?

It's really hard to see quite what it is that you hope to achieve through this mechanism, and whatever it is, my instinct tells me you are on a hiding to nothing.

If you describe your high level goal for this arrangement, maybe there is a better way of achieving it than abusing MMF this way?