[Pharo-users] Memory mapped files and Pharo (aka Unreal Engine 4 integration with Pharo)
kilon.alios at gmail.com
Sun Jan 17 16:18:22 EST 2016
Pipes are actually slower than sockets (local UNIX sockets that is) and I
dont need sockets if I am using shared memory.
I could create an event que and not allow direct access to shared memory,
this way I make sure everything happens in order and in sequence. This way
I can make sure multiple writes and reads dont happen at the same time.
This could be a first implementation and if the need arises for multi
threading then I can revise this design but frankly I rather stay away from
multithreading and other complexities and keep this simple and easy to
learn and code.
On Sun, Jan 17, 2016 at 10:19 PM David Allouche <david at allouche.net> wrote:
> First a disclaimer, I do not have a lot of experience with inter-process
> communication (I have a bit, though), and no direct experience with mmaped
> On 17 Jan 2016, at 17:41, Dimitris Chloupis <kilon.alios at gmail.com> wrote:
> 1) Do you think this is possible with the current Pharo ?
> 2) Will I be limited by the fact that the VM currently does not
> multithread or cannot use multithreading libraries ? ( I have no intention
> of using multithreading but some handling of process access to the data may
> be necessary to make sure data is safe from concurent modification)
> Communication through mmaped files, or shared memory in general, is
> inherently asynchronous, so lack of multiple OS threads should not be a
> blocker if the protocol is well designed.
> 3) Is there anything else I should be aware of as common pitfalls for such
> implementation ?
> I expect you would need some sort of out-of-band signalling so polling is
> not necessary. Pipes or sockets could be used for that, slower for data
> transfer (more copying), but they are compatible with select() and other OS
> polling features.
> You could build synchronisation primitives on top of sockets, too. But
> building things like mutexes would be inefficient. I guess you could use
> pipes for all the message sending and memory management, and shared memory
> for bulk data transfer. Large number of messages could be handled in batch
> this way:
> - allocate a message area (socket round trip)
> - fill the message area
> - signal to process a block of messages (socket one way)
> - optimistically check for incoming messages in shared memory
> - wait for socket input
> Not very efficient for messages that depend on one another. But I am not
> sure you could do better without things like interprocess semaphores or a
> 4) Can the current FFI help in this task or would I need to implement this
> as a C DLL and load it from Pharo
> PS: I have no intention of messing with the Pharo VM and I also want to
> avoid the use of plugins as I want this to work with standard Pharo
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-users