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. Uko On 02 Dec 2013, at 14:21, Esteban A. Maringolo <emaringolo@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@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