[Pharo-users] Memory mapped files and Pharo (aka Unreal Engine 4 integration with Pharo)

Dimitris Chloupis 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
> files.
>
> 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
> FFI.
>
> 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
> distributions.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160117/0da5764c/attachment.html>


More information about the Pharo-users mailing list