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 <[email protected]> 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 <[email protected]>: >> 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 >
