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 <[email protected]> > On 02 Dec 2013, at 19:30, Stéphane Ducasse <[email protected]> > 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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> wrote: >> >> >> On 02 Dec 2013, at 17:42, Sean P. DeNigris <[email protected]> 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/>. >> >> >> >> >> >> > >
