[Pharo-dev] Responsible development

Esteban Lorenzano estebanlm at gmail.com
Mon Dec 2 08:27:35 EST 2013

yes, tocayo, you are right... but there is a design problem since ever and
fix that will not be easy.

Also, there is the notion of "main thread" internal to pharo, and the "main
thread" relative to the OS. And AFAIK, the vm runs in the main thread (in
mac there is a line to uncomment for moving out main thread, but they were
a problem with certain callbacks who prevent me to use it... but well, we
should review that too).


On Mon, Dec 2, 2013 at 2:21 PM, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131202/762fe765/attachment-0002.html>

More information about the Pharo-dev mailing list