Hi Ben, On Sat, May 9, 2015 at 8:18 AM, Ben Coman <[email protected]> wrote:
> > > On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <[email protected]> > wrote: > >> >> >> On Sat, May 9, 2015 at 7:09 AM, 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. >>> >> > 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. > So what about doing something such as remembering the last time the transcript updated the UI, and a) not allowing #changed to update the UI if it has been less than x milliseconds since it was last updated, and b) scheduling a deferred ui update when #changed is filtered-out in this way and c) cancelling the deferred ui update if another transcript update occurs before the deferred update is processed. > 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 >>> >> > > > -- best, Eliot
