Closed JCash closed 1 year ago
The virtual memory buffer allows trivial, lock-free multiple producer/single consumer message passing, with no need for wrap-around detection and (potentially unused) over-allocation.
Whether this is absolutely necessary for high-performance message passing in Remotery or whether we're not pushing events fast enough to justify it, is untested: this is just how it was written in the first place.
So right now there is no scope for changing this as it runs on all supported platforms. Changing it would require both a new implementation and performance research demonstrating no perceivable loss of functionality. That's quite a big task and not one I can personally invest in.
Yeah, I'm currently wondering if I can write a mmap()
shim, using the private sdk.
I'll ask on their forum if anyone else has done it previously.
It seems like I will need to add a custom hook to create the virtual memory on the platform.
Just so I understand: are you saying that the platform has no virtual memory API at all... or that it just doesn't implement mmap
?
I support an NDA'd platform for a client that has its own API and no mmap
so I just #ifdef
the implementation into the Remotery code. Is this what you are thinking of doing or are you thinking at a much higher level where Remotery has callbacks for this kind of thing?
It does have a virtual memory api in its SDK, but it doesn't have a "mmap()" implementation.
Personally, I would be happy with #ifdef
-ing the code in Remotery.c (in our engine), with some calls to some new function that sets up this virtual memory.
Right, OK. So nothing to see here until we maybe need some extra callbacks in rmtSettings
:)
On some platforms there is no
mmap()
implementented. (There may be other api's under NDA)Is it possible to create some vanilla implementation of
VirtualMirrorBuffer
that one could fallback on? Currently, I have to disable the Remotery library since it's not working on this platform.