Le 14/02/2018 à 20:19, Stephane Ducasse a écrit :
Thanks Pavel this looks quite fast :).
Do you have a scenario in mind that could take advantage of this?

I'd be very interested to see that used with image segments for objects migration between images running in different processes (or coupled with a distributed shared memory implementation like [1]).

If latency is low enough, I think multi-window applications could be developped as multi-process single window images (and we could get scalability to thousands of cores, if the application design is right. Even code synchronisation between images would be easy to do).


[1] https://hal.archives-ouvertes.fr/hal-01679052


On Mon, Feb 12, 2018 at 10:33 AM, Pavel Krivanek
<pavel.kriva...@gmail.com> wrote:

among other less interesting things, I spent some time on existing
PosixSharedMemory project. It is a UFFI binding for the LibC methods
that provide support for the memory allocation between several
separate processes. I significantly improved the performance by
implementing the block access. Writing of 10MB byte array takes about
1 millisecond, reading of it from other image took me about 4
milliseconds. While serialization with Fuel is very fast, it opens
interesting possibilities.
To have a shared memory without synchronization tools is not very
useful so I wrote a basic UFFI interface for the POSIX named
semaphores. They are quite easy to use and work nicely with Pharo. The
VM can all wait on the semaphore or it can check the status of it
periodically in an image thread. It has two small disadvantages. It
requires to dynamically link the next library (pthread) and they must
be cleaned manually. I plan to look at System V alternative in future.
Now we should write a nice framework for inter-image communication on
top of it or/and adopt Seamless for it ;-)

-- Pavel

Reply via email to