On Sat, May 9, 2015 at 11:00 PM, Sven Van Caekenberghe <[email protected]> wrote:
> > > On 09 May 2015, at 16:41, Ben Coman <[email protected]> wrote: > > > > > > > > On Sat, May 9, 2015 at 10:09 PM, Ben Coman <[email protected]> wrote: > > From my limited experience bug hunting, calling #changed: from a thread > other than the UI thread is a source of evil. There are too many > assumptions throughout the system that the UI is single threaded. Can > anyone advise me that is not a proper belief? > > > > Then that implies that a Transcript implementation where #nextPut: > direct calls #changed: > > is not appropriate for use with multi-threaded applications. In Pharo, > #changed: is only called from #stepGlobal, which is called from > doOneCycle:. (This came about as a last minute bug fix before Pharo 3 > release and maybe could use some cleanup. > > > > Separating the UI from Transcript into its own viewer might be a good > idea, but actually it would not solve Stef's case since his code would > still be running in the UI thread -- unless the viewer ran in another > thread, which would have its own complexities. > > > > I think the point about efficiency is significant. The following > example... > > Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' > ] ] > > on Squeak 4.5 --> 12749ms > > on Pharo 50029 --> 2ms > > > > As a point of comparison, on VW 8.0 --> 43817ms > > and so you might guess, VW 8.0 outputs each 'x' immediately. > > cheers -ben > > I am not sure, but in VW it looks like each Workspace (Window) is > (executing its Doit) in a separate thread. > Nice pick up. I checked and for each opened workspace their Process Monitor shows another process labelled "Workspace." Executing the example from the original post in a Workspace shows that Workspace waiting on the delay. So this aligns with one of the suggestions above. cheers -ben
