1. AFAIK, "cannot tie() threads::shared variables" ne "cannot clone tie()'d variables"

I'm not using threads::shared anything. I create a mmf-tied variable in the root thread/process. When a new thread is spawned, it should clone everything, including the tied variables. If this assumption is false, then all of ithreads - including the Win32 fork() emulation - pretty much drops dead wrt tie(). (I can't seem to find the reference for the "can't tie threads::shared variables", but I know it exists; I'm not aware of a similar restriction wrt non-shared tie()'d variables..if it exists please advise of the docs which say so. I do realize that a tie may require a CLONE method, and perhaps thats whats lacking in Win32::MMF::Shareable)

2. I don't need to share the memory between the threads, other than to manage the region allocation map. But I do need to share the memory with an external process, namely, plstrace, that inspects the mmf to dump it for inspection.

3. I'm re-mapping because prior problems led me to Re: Perl forking and shared memory strangeness under Windows (you may recognize the author ;^). With the remapping, I'm able to get a bit further than before. (Interestingly, I had to do the same thing for Sys::Mmap in Linux, tho wo/ re-require'ing, nor re-opening the file, just re-mmap()ing).

4. As to plstrace's "safety", suffice to say I'm not concerned. The data being written by DB::DB is a reasonably fixed format, every thread of every process only accesses its own segment of the mmf, so there's no overwrites. Its no different than 2 processes writing to the same file, but the first only ever uses the first 10K, and the 2nd only ever uses the 2nd 10K. As to the "garbage", plstrace won't have much difficulty sorting it out, and deciding whether to ignore a timestamp or a string-length indicator because its not valid. (FWIW, I've done this sort of thing many times before in C)

So it boils down to:

a) does ithreads cloning properly handle tie()'d variables

b) does Win32 handle multiple mmf's to the same file (why it should matter seems odd to me, but I suppose its possible the page table mapping onto the filesystem buffers might preclude duplicate page table entries mapped to the same physical address)