2009/8/7 Dale Henrichs <[email protected]>: > Igor, > > I appreciate what you are saying and in the fullness of time, we may be able > to do more things with background processes. > Sure :)
> However, we _are_ running a development environment for GemStone that should > appear to the user to be no different than the Pharo development environment > ... i.e., when you evaluate the following expression in Pharo or The GemTools > client: > > 10 timesRepeat: [ (Delay forSeconds: 1) wait ] > > you would expect the UI process to be blocked for the duration of execution. > This is why I _block_ the UI process during execution. yes it is blocked, since this expression runs in the UI process itself and therefore it can't handle any user input before quitting it. > > If you have a long running process running in the foreground (whether or not > it is running on GemStone) you expect to be able to interrupt the process and > bring up a debugger on the interrupted process. In order to do that with the > GemTools client, we have to use a non-blocking C call, so that the GemTools > client can recognize the interrupt and take appropriate action. This is why > we are using a non-blocking call. Sure. I'm using interrupt key time to time. But if you wouldn't block the UI process, you can, instead, let user click on 'interrupt' or 'cancel' button. Isn't that more consistent approach, than letting user to wonder cluelessly, what is happening and why UI not responding? :) > > With that said, something subtle _has_ changed in the way that the Pharo UI > processes updates windows ... In earlier versions of Pharo, the Transcript > window (whether or not it was thread-safe) updated without any special effort > on my part, with the 1.0 beta, the transcript window is not updating. I've > tried both thread safe and non-thread safe Transcripts and it doesn't appear > to matter. > > While poking around, I have discovered that the transcript is not updated > until the process finishes in Pharo either. So the following expression > "misbehaves" whether executed in GemStone or Pharo: > > 10 timesRepeat: [ > (Delay forSeconds: 1) wait. > Transcript cr; show: 'hi' ] > > I guess I _expect_ the display to be updated whether or not I am running a > process in the foreground. > then you need to explicitly put the code which can do 'update', as you doing below. > If I insert a 'World displayWorldSafely' into the loop then the transcript is > updated 'correctly': > > 10 timesRepeat: [ > (Delay forSeconds: 1) wait. > Transcript cr; show: 'hi'. > World displayWorldSafely ] > My guess that maybe 'World doOneCycle' be more appropriate? > Is this expected behavior and the correct solution to my problem? > Seems so. And this is makes your code non-thread safe, since it could run safely only in the UI process. [snip] Btw, going beyond the topic, i thought that in future, its maybe worth to think about creating a special 'watchdog' which watching that each world cycle is no longer than 1 sec. If its longer than that (like when UI blocked by some lengthly process), then watchdog spawns a new UI process and revokes the old UI process from being that one. Then things like: 10 timesRepeat: [ (Delay forSeconds: 1) wait ] will eventually start running in background, always giving the user be able interact with UI, despite anything what could happen with current UI process. This seems a brute-force approach, but consider it as my personal POV: blocked UI stinks :) -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
