Regarding the first part of your email, about UI lockups, it is almost unavoidable, because in Pharo almost everything happens in the main thread, as you pointed out. When only UI events should happen there, and have background processes/async tasks for computation and I/O that updates the UI by means of some sort of message channel between the process and the UI.
This isn't a "feature" of Pharo only, other Smalltalks[1] have the same "design" (or lack thereof) regarding what it is done in the main/UI thread. I can't imagine a plan for changing that in the current tools, I think it would require a major overhaul. OTOH newer tools like Spotter seems to use background threads to do its stuff, so the shift might have already begun. Regards, Esteban A. Maringolo [1] VisualAge came with an separate OS process that could halt the vm at a very low level when it was stuck in a tight loop. ST/X has a process/message queue per os window, which allows you to kill one window without taking down the whole image/vm. 2016-06-03 2:56 GMT-03:00 stepharo <steph...@free.fr>: > the mooc is a mine for Pharo bugs... > > > In the video at 6:12, we have a new method sending the new message. I've > made similar mistakes and Pharo does lock up, but then the operating system > (Windows 10) kills the Pharo VM. (Or perhaps there's a bug in Pharo itself > which just crashes the whole VM. I can't tell the difference.) > Is that because it's a memory leak? Does the VM have a fixed amount of > memory available, or can it request more from the OS? > Is there a way to recover from this error without killing the whole VM? > Most GUI systems I've used have at least two threads so that pushing a > button doesn't lock up the whole UI if the task takes a while. Does Pharo > always lock up for long-running tasks, or does it have some kind of > threading ability too? If a background thread gets in an infinite loop, how > do you kill it without killing the whole VM? > > > here was my answer > > The real answer is a bit more complex so I may write some approximations: - > what you did a really tight loops that fills up the memory really fast. - > depending on the OS the VM can or not (in its current state) allocate more. > In some versions it has to preallocate. > "Most GUI systems I've used have at least two threads so that pushing a > button doesn't lock up the whole UI if the task takes a while. Does Pharo > always lock up for long-running tasks, or does it have some kind of > threading ability too? If a background thread gets in an infinite loop, how > do you kill it without killing the whole VM?" > Pharo has a full model for concurrent programming. Check the class Process, > Semaphore. We have some stress tests that create thousands of threads > without problems. You have also package such TaskIt to schedule tasks > Now the actual problem that you see and that I would love to see fix in the > future is that the code you execute is run in the UI thread (arghhhhh) It is > still like that for historical reason. We should do one pass on that but > this is not that simple because it will raise a couple of bugs. > > > Now I think that it would be great if people from the pharo core would > browse in diagonal the problems that students > > encounter because there are our real customers and they show many problems > of the system. Especially the ones we do not see anymore. > >
