I do feel that this issue fall more under the jurisdiction of Exception Handling, where if something bad happens to your system the whole thing does not collapse on itself but rather reports the error and carries on.
Pharo processes are not OS processes, correct me if I am wrong but they dont have their own memory or can get their own core and generally are not separate entities. They are not even real threads. So I doubt how much of a protection they will offer. But agree with your its a design issue that sooner or later will have to be addressed. If the systems is very complex , then later is more likely. On Mon, Dec 2, 2013 at 3:32 PM, Yuriy Tymchuk <[email protected]> wrote: > 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 > > > > >
