[Pharo-dev] Responsible development

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Dec 2 15:15:07 EST 2013


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 at gmail.com>

> On 02 Dec 2013, at 19:30, Stéphane Ducasse <stephane.ducasse at 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 at 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 at 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 at me.com> wrote:
>>
>>
>> On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean at 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/>.
>>
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131202/d0fc481b/attachment-0002.html>


More information about the Pharo-dev mailing list