Igor,
I appreciate what you are saying and in the fullness of time, we may be able to
do more things with background processes.
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.
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.
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.
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 ]
Is this expected behavior and the correct solution to my problem?
Dale
----- "Igor Stasenko" <[email protected]> wrote:
| 2009/8/7 Dale Henrichs <[email protected]>:
| > I'm trying to characterize some differences in behavior for GemTools
| between Squeak and the 1.0beta for Pharo. I'm not reporting a bug as
| much as trying to understand what I need to do differently in Pharo.
| >
| > In GemTools, I have a special workspace (GemTools Launcher), that
| causes doits to be evaluated in a GemStone server. This is done by
| using FFI to make calls to the GemStone GCI library.
| >
| > The string is passed to GemStone via a nonblocking C call. On the
| Pharo (client) side, we poll for a result. While an expression is
| evaluating, exceptions may be raised on the server-side and on the
| client, we convert the gemstone exception into a Pharo exception and
| signal it, if/when the exception is resumed, we pass a result back to
| the server and continue waiting for the result of the original
| expression.
| >
| > There are two thing that might happen when a exception is raised in
| this manner. If the exception is an error, we bring up a debugger
| window on the client and arrange to debug the process on the server
| (again using the GCI). If the exception is what we call a Client
| Forwarder exception, then we arrange to send a message to the client
| object and pass the result back to the server side. Using a client
| forwarder, the server can send messages to the client Transcript with
| logging/progress messages.
| >
| > In earlier versions of Pharo and in the current version of Squeak,
| when we sent messages to the Transcript, the messages would show up
| immediately ... making it easy to watch progress of long running
| operations.
| >
| > In the 1.0 beta Pharo, this behavior has changed. It appears that
| the Transcript window is not updated until the polling process
| finishes, which makes the progress messages a little bit less than
| useful.
| >
| > I assume that I need to add a message to my polling loop to allow
| for display updates...I'm doing a Delay wait in the loop so the
| process is not in a tight loop.
| >
| > I am not running the poll in the background, because I want the UI
| process to be blocked ... this same mechanism is used for menu items,
| etc. so blocking is important.
| >
| > Thanks for the help,
|
| Dale, the key problem of this is that 'wait loop' blocks the UI
| process. I know, it is simplest way to prevent user from doing
| anything while system is busy but its not very friendly, especially
| when you need to perform a remote processing which requires a
| substantional amount of time to complete.
| But, i wonder, what is the point in using a non-blocking calls to
| communicate with GemStone, when in the end its still blocks
| everything
| (from user's point of view) ? :)
|
| Stef did a good job making a Transcript thread-safe in Pharo, so it
| can be used by any process (not only UI one) safely.
| But this implies that you should not block the UI thread to give it a
| chance to update the screen. In case if nothing blocks the process,
| the transcript window will be updated each 20ms or so (World update
| cycle), and such delay, i think will be hardly noticeable by users.
| Transcript is a stream , which updated immediately once you putting
| something to it, but there are no guarantees that any other objects
| (like window , which is displaying its contents) should be updated
| immediately as well.
|
| I am encouraging you to create a background process , which talks
| with
| GemStone, and then UI process just schedule user actions to it. This
| will make UI process non-blocking, but of course, requires additional
| efforts, like disabling the user from doing anything while waiting
| response from G/S. But this could be done nicely, and user could go
| to
| any other window/menu etc, and do things there while G/S processing
| the actions. Which i think makes UI much more friendly.
|
|
| >
| > Dale
| >
| > _______________________________________________
| > Pharo-project mailing list
| > [email protected]
| > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| >
|
|
|
| --
| Best regards,
| Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
