[Pharo-dev] Erlang/OTP/Pony-style concurrency in Smalltalk

Shaping shaping at uurda.org
Fri Nov 29 16:41:50 EST 2019


(I posted this earlier to the OS VM group
(vm-dev at lists.squeakfoundation.org), but the message appeared as an
attachment.  I'm not sure that was the right place; so I'm reposting here.)

 

 

Hi all. 

 

I was reading about the RoarVM, recently.  The project seems to be at a
standstill.  

 

Why, as in the RoarVM, would someone try to build a Smalltalk VM supporting
concurrency, and not also resolve to use a strict actor model in which each
process has its own, usually small heap that is very quickly and simply
GCed?  If I understand correctly, RoarVM still had one big heap for all
processes.  With one heap per process, many times no GC happens at all:  the
process finishes and the heap is discarded.  This finer-grained
memory-management dynamic gets us closer to deterministic latencies, which
are needed in simulations (and almost anything graphical you want to render
smoothly).

 

The idea with the actor model (and the OTP-style work-stealing that
accompanies it) is not only to use very continuously all cores in all CPUs
in all machine-nodes on the network, all of the time (until the program
exits or goes idle), but also to make using the usual synchronization
devices (semaphores, mutexes, monitors, and the like) unnecessary.  This is
where all the complexity is and where the time and effort go when coding and
debugging concurrent apps.  No one wants to use these devices if he needn't.
The actor model is an elegant way to solve the concurrent-programming
problem, which mostly reduces to advancing program state with only
asynchronous messaging, while causing no blocking and no idle cores if there
is still work left to do.  The actor model works if you are willing to build
a proper state-machine for your app (I have some ideas for a GUI to help in
this respect) and the asynchronous messaging is fast.  It is very fast in
Pony (https://www.ponylang.io/).  (Smalltalk images linked by WS connections
won't be fast enough.)

 

I'm learning to use Pony these days.  It's a good tool, and it's improving
at a good pace with an enthusiastic community.  It's statically compiled; so
it's not speeding development/experimentation as much as it is the resulting
program.  However, Pony vastly reduces the amount of concurrency-related
debugging you would otherwise do if you did not, after a successful compile,
have a provably non-deadlocking/non-data racing program.  This is the new
thing that Pony gives you, and it's great.   But I want a dynamic
development environment and very efficient Erlang/OTP/Pony-style
concurrency.

 

How do we get that?

 

Why wasn't this the path chosen by the RoarVM developers?

 

What is happening in OpenSmalltalk VM regarding such concurrency?

 

I'm considering using Pony somehow in a 5-pane browser (but that's some
work), dumping compiler errors to the Transcript.  I'm not fond of editing
text files (scrolling/searching) even when the process is very graceful.
That's too 20th-century.  VS Code is a very nice tool with great extensions,
but it does not replace what happens in a Smalltalk browser.   

 

Please share your thoughts on what is happening or what could be done to
create Erlang/OTP/Pony-style concurrency in Smalltalk.

 

 

Cheers,

 

Shaping

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20191129/d626bde2/attachment.html>


More information about the Pharo-dev mailing list