[Pharo-dev] Responsible development

Pavel Krivanek pavel.krivanek at gmail.com
Mon Dec 2 09:28:59 EST 2013


User interrupt (cmd + .) was not working?

-- Pavel


2013/12/2 Esteban A. Maringolo <emaringolo at gmail.com>

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131202/94679356/attachment-0002.html>


More information about the Pharo-dev mailing list