Thanks for posting the link to the original post , I tried to find it but I failed. On the matter why people did not reply is probably because the idea is too "vague" and very "theoretical" and probably because the post is long. Just for the record I have since dismissed as an idea both the C-image and shared memory model. The bad news is that Apple does not allow one executable to run another executable in iOS which means the pretty much kills the very foundation of my idea and makes it impossible to use Pharo with Unreal on iOS. OpenMP wise again, I found out that Unreal has its own threading model which is very easy to use and runs under the hood. So I dont need that either. "I guess you won't avoid session management with this idea of memory mapped C-image, since the external resources provide from the OS like files, display buffers, network buffers & GPU threads would still be destroyed by the OS when Pharo exits. Consider the case of moving your Pharo-image + C-image to another machine. " No session management is still necessary , the goal was not to make it redundant but rather to keep live state of the C side. But that of course that means that this would not work automagically , the C code will have to use the shared memory mapped file or else the state would be lost. You will need a session manager to trigger the functions that were running at the time the c image file was closed but those functions would be able to continue from where they were left since the state would be restored. "Just to clarify (for myself also if someone likes to correct me) I have gathered the idea that Slang should be thought of less as Smalltalk compiling to C, and more as C with Smalltalk syntax which works well with our usual tools. So compiling Slang to C is "trivial" compared to compiling general Pharo code to C. The trick I guess would be dynamically generating and compiling the C code and then linking it back in. " No not really, its actually the first. Slang has a lot of things C can do that slang cannot do this is why much of the VM is written in C and not Slang. There you expose another weakness of my idea that Slang would need an overhaul to do what I want. "I think applying some kind of OpenMP pragma to random parts of the image's code would be quite difficult because it of the interaction with the VM - but if it was restricted to code that ran detached from the image (e.g. in a separate native or on a GPU) then that could be interesting -- but I can't think of how you would marshall parameters and results between them. " it should not be a problem since the threading would happen in the separate process that VM does not depend on , pharo would have only access to the shared memory. So basically it would be like Pharo: C calculate this with X many threads and when you finish share the result in this part of the memory C : Sure buddy in a few minutes you will have your result , i will alert you Pharo: Thanks mate. In any case that was a pure "theoretical" idea, I posted here to find its weaknesses. I see now its not such a good idea as I initially though for the above reasons. It looks like I wont be using Pharo so much with Unreal afterall since the only viable solution would be to embed it which currently is not possible at least the easy way. Oh well I may still use Pharo here and there to automate some Blender and Unreal stuff :) -- View this message in context: http://forum.world.st/Pharo-and-OpenMP-tp4874277p4875558.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.