On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.mira...@gmail.com> wrote:
> > > On Sat, May 9, 2015 at 7:09 AM, Ben Coman <b...@openinworld.com> wrote: > >> From my limited experience bug hunting, calling #changed: from a thread >> other than the UI thread is a source of evil. >> > 3. Thinking further on this, I suppose the main issue from the original example is that its running in the UI thread. In this case I guess calling #changed: and #refreshWorld is okay (there have been no problems in Squeak). So in ThreadSafe>>endEntry we could check to see if we are in the UI thread and only in that case issue #changed:. So only the "user interactive" workspace will see the "slow" behaviour (which any is too fast for a human to notice), and forked processes will not be slowed. cheers -ben > 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 >> >> This better performance helped me a lot trying to understand the high >> priority timerEventLoop being able to indiscriminately scatter Transcript >> tracing through that code. I believe its also probably beneficial for >> working with externally triggered semaphores and timing sensitive race >> conditions. >> >> So we have two mutually exclusive cases: >> * better interactivity, poorer system performance >> * faster system performance, worse interactivity >> >> Which of these is broken depends on your viewpoint. >> > > Something that runs fast but is incorrect is still incorrect. The fact > that the transcript doesn't output until a world step is possible is a > bug. It forces programs that use the transcript to be rewritten in order > to see transcript output. > > >> For which I see two solutions: >> 1. Next to the doIt menu item add a forkIt menu item -- so its >> optional, but not the default >> 2. Have a Preference that enables Transcript>>nextPut: to call #changed: >> > > Is this the entire solution space? > See (3.) above. 4. Run Workspaces in their own thread per VW (but that already got knocked down) > Are there not ways of engineering the transcript to update at, say, 10Hz? > Can the transcript not be made to render changes much faster? > Still thinking about these. > I see terminals with performance thousands of times faster than the > transcript that still display output immediately. I don't understand why > the Squeak transcript is so slow. That's a bug also. > > > >> >> The first I think could be useful anyway, not having to do a cumbersome >> coded fork. This would also provide a measure of documentation and >> discoverability. There might be a submenu for forking at the different >> user priorities. >> >> For the second, it would be pragmatic to do what we can to facilitate VM >> development on Pharo. The preference can describe how it might adverse >> affect multithreaded applications. >> >> cheers -ben >> >
