[Pharo-dev] Responsible development

Yuriy Tymchuk yuriy.tymchuk at me.com
Mon Dec 2 08:32:08 EST 2013

Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial.


On 02 Dec 2013, at 14:21, Esteban A. Maringolo <emaringolo at gmail.com> wrote:

> Sidenote about this.
> I don't know about this particular problem you faced with Nautilus.
> But the issue is "unfixable", IMHO, because everything runs in the
> same process.
> So there is no way to stop the current active process if it is REALLY
> stuck (100% CPU, 1 CORE). If it gets into an infinite unbreakable
> loop, or indefinitely blocking on I/O, then the entire VM gets
> unresponsive.
> For that reason I think that nothing should run in the UI Thread
> (which in Pharo is the main thread), except for event handling and
> rendering. Or... the VM should notice abnormal processes eating a lot
> of resources and warn the user.
> That's one nice feature of Smalltalk/X, every windows runs its own
> thread, with its own event queue, etc. You can kill it safely, without
> trowing away the whole image.
> Regards!
> Esteban A. Maringolo
> 2013/12/2 Yuriy Tymchuk <yuriy.tymchuk at me.com>:
>> Hi guys, I have some thoughts about how we develop for Pharo.
>> I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo.
>> Uko

More information about the Pharo-dev mailing list