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. > > 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. >>>> >>> >>> >> > >
