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
