6 ms·
Isn't an object is already an actor in Smalltalk?
by throwaway487548 8y ago
Isn't an object is already an actor in Smalltalk?
- mbrock 8y agoNope. Smalltalk objects aren't concurrent or asynchronous in any way. Smalltalk "messages" are good old method calls.
- pjmlp 8y agoSmalltalk supports multicore since the early days, in fact the Blue Book even has some examples for data simulation.
- igouy 8y agoSimulations can be done on one time-sliced processor! Which main "Smalltalk" are you thinking of when you say "supports multicore since the early days"? There certainly have been research Smalltalk implementations that do, like: "Multiprocessor Smalltalk: A Case Study of a Multiprocessor-Based Programming Environment" https://www.researchgate.net/publication/234768128_Multiprocessor_Smalltalk_A_Case_Study_of_a_Multiprocessor-Based_Programming_Environment https://www.researchgate.net/publication/234768128_Multiproc... and more complete implementations like Actra and Gemstone/S.
- pjmlp 8y agoThe reference to the Blue Book made it quite obvious. Thanks for the paper reference. As for Gemstone I was aware of it. :)
- igouy 8y ago> reference to the Blue Book So you mean ParcPlace Smalltalk-80 "supports multicore since the early days"? I think those Smalltalk "processes" are run in the same OS thread and only use one core, so please explain what you mean. Were you aware of Actra?
- pjmlp 8y agoAfter re-reading the Process/ProcessScheduler chapter you are right, it explicitly mentions one VM per CPU. So from that point I stand corrected, however I would say it was an implementation detail, as the ProcessScheduler could easily have other policies.
- igouy 8y ago> implementation detail There's an enormous chasm between research experiments: September 1988 "From Objects to Actors: Study of a Limited Symbiosis in Smalltalk-80" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.7827&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.... :and well-understood techniques supported by all the programming tools.
- pjmlp 8y agoThanks for the paper.
- throwaway487548 8y agoOh, my bad. Erlang's processes are actors, not Smalltalk objects, sorry.
- tonyg 8y ago(To nitpick: there's a heck of a lot of concurrency, a property of system design, language design, and problem domain, but not much parallelism, a property of the specific VM in use. Smalltalk systems are usually managing interactivity on multiple fronts at the same time.)
- throwaway487548 8y ago> Smalltalk "messages" are good old method calls. Technically, this is not exactly true. Messages are propagated to superclasses if an objects has no receiver, so they are more messages than method calls. Also, the design decisions were to make objects an isolated entities which communicate by message passing. They does not have implicit mailboxes like it is in Erlang, and are not strongly-isolated, share-nothing entities (which is what makes the whole system fault-tolerant). However, objects are definitely has some concurrency, but no async features in modern terms.
- jcelerier 8y ago> Messages are propagated to superclasses if an objects has no receiver, so they are more messages than method calls. are they ? this could be implemented with simple vtables and function pointers, without any difference in the case of a function being present or not in the child class case
- mapcars 8y agoSmalltalk "messages" are not asynchronous, but they are also not "good old method calls." One example of that is that objects handle any message and if it doesn't know how to reply by default (defined in Object class) it raises an error. But this can be redefined (message doesNotUnderstand:) to do anything you want.
- dasmoth 8y agoThe original Smalltalk was pretty close. By Smalltalk-76, they'd switched to calling methods synchronously (although still naming the calls "messages", I believe).