Stef wrote >Now for example you can load code in a background process now if >you modify objects that may be impacted by changes then you can get in >trouble.
Here is a live example of doing that: This is how we load Delphi code in Moose. http://www.flickr.com/photos/35787002@N03/10609428345/ In the background. That is very nice when it works. But not so nice when the background process keeps on popping up debuggers. Lots of debuggers. So many, that it gets difficult to get access to the process browser to kill the loading process. As long as the proces ends and you don’t run out of memory, you can then kill all open debuggers with some code like World submorphs select: [:each | (each respondsTo: #label) ifTrue: [each label beginsWith: 'Message’] ifFalse: [ false] ] thenDo: [:each | each close] And then you wait a few minutes for the debuggers to be closed. Ben wrote >I will do an experiment and fork each Nautilus opening to see if it can save >my ass :P Background processing only works in a very specific setup. This won’t work when every nautilus browsers just runs in its own thread, as nearly all code in Pharo is not thraad-safe. Is the compiler reentrant? Or even woorse, is committing packages reentrant? >I was saying that theoretically it should not freeze the UI thread if you fork. How are you going to find the one thread that does something wrong and freezes the UI? Stephan
