Memory mapped files and Pharo (aka Unreal Engine 4 integration with Pharo)
An apology for the long post but this is not a simple issue and hence not a simple question. So I am looking into ways to integrate Pharo with Unreal to bring some nuclear powered graphics to Pharo and make us first class citizents to 2D and 3D world. For those not aware this is unreal https://www.unrealengine.com/what-is-unreal-engine-4 As suprising it may sound Unreal and Pharo share a lot in common 1) Both integrated languages with IDEs 2) Both promote live coding and live manipulation of data 3) Both promote visual coding 4) Both promote ease of use and wizard based development (aka RAD) Unreal is indeed a C++ based project made to be used by C++ coders but it comes with a very powerful visual coding language that can map visual nodes to any C++ function/Method and another common ground with Pharo is the very strict OO nature of both projects. But then OOP is very big in game development anyway. Of course my goal is not to force Pharoers to learn C++, but rather make a Pharo API so Pharo can be used to do some simple graphics development in the start and then we can continue importing more and more functionality. Unreal is generally a heavy engine that requires quite a powerful GPU but its rendering is just amazing. So how I make Pharo talk to Unreal is the million dollar question. The road of compiling Unreal as a set of DLLs to be loaded by Pharo via FFI is a road full of thorns because its quite an undertaking cause Unreal is HUGE and it will be nightmare to maintain since Unreal moves forward very fast. So we come to the subject of IPC, or Inter Process Communication. I am not new to this as you know I have build a socket bridge between Pharo and Python that allows Pharo to use Python libraries and in my implementation I focus on Blender Python API. But sockets are not exactly blazzing fast, calling functions is fine because you can even get responses bellow 1 millisecond but if try to run some heavy loops you will be in trouble. There are work arounds of course, like sending the loop with the socket and language etc but they overcomplicate something that at least in my opinion should remain simple. Another IPC method is shared memory, it is what it says , basically processes that share a place in memory where they can access the same data. Extremely fast but it has its own traps for example how to make sure the processes dont access the same data at the same time etc. So after some reading I came across to a shared memory model called Memory mapped files, basically what that means is essentially a virtual file that resides on memory (it may also reside on the hard disk or other permanent physical storage but its not necessary) that different processes can access. So in our case we can have memory mapped file that Unreal , Pharo and even Blender can access where we can store command / messages that each diffirent application must execute, let them share data and sky is the limit. Now I know this will not be a walk in the park specially to someone like me a C++ noob but I am looking for the Pharo wisemen wisewomen to guide me at least through the obstacles of this. So the questions are the following 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) 3) Is there anything else I should be aware of as common pitfalls for such implementation ? 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.
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@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.
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@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@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.
On 17 Jan 2016, at 22:18, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
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.
You will still need a signalling channel so either side knows that it has new commands to process without having to poll.
the way I see it at least, polling is not a problem, Graphics work on frame loop, that means actions that have to repeat per frame , Unreal objects are constructed around this functionality , same way we have a World cycle that drawOn: methods work , then of course you have event loops etc. A signal mechanism would have been a callback functionality but frankly I dont think its necessary. My goal is to bring unreal closer to pharo , so that means I will use similar functionality to Morphic and Bloc for drawing to make easy for pharo guis to port to unreal because unreal is not only capable of 3d but also 2d graphics. So the idea is when the frame loops starts , execute first what Unreal has to execute , then read a message qeue where pharo will register messages very similar to pharo messaging . I may allow Pharo to assign messages to specific frames. Those messages will call functions/methods of the Unreal API. Of course it can work vice versa so that Unreal becomes aware of the Pharo enviroment and callback pharo mehods etc and even Blender methods (for asset creation) and I could even hook on this message que many other applications essential to build a common language that apps and libraries can talk to each other without depending on specific implementation and wrapper APIs. Thats the general idea , so far, open to redesign and rethinking depending on the obstacles I may face. On Mon, Jan 18, 2016 at 10:14 AM David Allouche <david@allouche.net> wrote:
On 17 Jan 2016, at 22:18, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
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.
You will still need a signalling channel so either side knows that it has new commands to process without having to poll.
participants (2)
-
David Allouche -
Dimitris Chloupis