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 <da...@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.al...@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. > >
