Of course, and obviously in Squeak/Pharo, code itself is kind of mutable state... (you modify some methodDictionary, subclasses etc...). So applying concurrency to tools handling that shared mutable state is... HARD. 2013/12/2 Frank Shearar <frank.shearar@gmail.com>
On 02 Dec 2013, at 19:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
In clojure they have STM so they can somehow control concurrent effect with readonly structure (I forgot). I thought that it would be interesting to see what would be an STM for Pharo but this is a real phdsssss topic.
On Dec 2, 2013, at 8:25 PM, kilon alios <kilon.alios@gmail.com> wrote:
there is also performance concerns. I remember once there was that code for a fractal or something that let you define how many threads it would use. 1 thread was very slow , 5-6 threads very fast but more threads actually made code slower and slower the more threads I was adding. And those were REAL threads (meaning the could take advantage of multiple cores = real concurency) , not greenlets as the ones used by pharo and python.
So there is always a catch. Concurrency is known to cause headache with the exception of Clojure and Erlang both seem to make their users very happy with their concurrency features. But both of these languages were based on concurrency and not added it in as another feature to have. These things are not easy to implement.
Both clojure and erlang have immutable state as the default. It is not concurrency that is hard. It is shared mutable state that kills you.
frank
I come from python , super popular language, tons of developer and loads of people complaining how concurrency is done.
On Mon, Dec 2, 2013 at 9:14 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P
:)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Ben
On 02 Dec 2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean@clipperadams.com> wrote:
Uko2 wrote
Itâs not about stability of pharo 3, it about concurrency... This thread doesnât seem to have any reason
Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread.
Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard.
Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too.
uko
----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.