Hi all!

--- Ned Konz <ned at bike-nomad.com> wrote:
> On Thursday 08 March 2001 15:35, "Göran" Hultgren wrote:
> 
> > [ self directory: aFileDirectoryWrapper withoutListWrapper.
> > brevityState := #FileList.
> > "self addPath: path."
> > self changed: #fileList.
> > self changed: #contents.
> > self changed: #getSelectedDirectory. ] forkAt: Processor
> > userBackgroundPriority -----------
> >
> > Hopefully this little hack will not break anything - I did the change
> > directly in the debugger and then saved it with Alt-s, killed the debugger,
> > reopened the filelist and tried clicking on Bobs SuperSwiki again.
> 
> Sadly, this will not work (in general) for the following reason:

I could have guessed! :-)
 
> #changed: tries to update the appropriate widgets. If you do this from a 
> thread other than the UI, things can get confused (imagine getting partly 
> through changed: from your background thread, then switching to the UI thread 
> and not having everything consistent in the UI objects).

Ah, yes, I thought that there might be a bunch of problems and I actually was expecting someone to
step up and smack me inthe face - I haven't done any UI hacking in Squeak yet.

Another perhaps more obvious flaw is that the hack has no semaphore or such so clicking around
selecting different directories would spawn off a lot of little forks probably stepping on each
other's toes...
 
> For much the same reason, the Transcript is not thread safe (if you write to 

That I actually knew but "suppressed"! ;-)

> it from multiple threads, they'll write on top of each other, and if you 
> write to the Transcript from a non-UI thread and try re-sizing or scrolling 
> the Transcript, it can blow up).

Ooops. Yeah, I have seen a patch for threadsafing the transcript floating around for some time,
but I will not try to beat that particular horse (I am not native english speaking so this might
have been the wrong expression... :-).
 
> > self directory: aFileDirectoryWrapper withoutListWrapper.
> this calls #changed and so cannot be done in a background thread.

Ouch. Yes, I see... Hmmm.

> > self changed: #fileList.
> > self changed: #contents.
> > self changed: #getSelectedDirectory. 
> Nor can these be done in a background thread.

Ok. So the UI thread should do all the UI. But we still want to be able to do stuff in the
background, like batch-jobs... Hmmm. In this particular case 92% (used TimeProfileBrowser) of the
time is spent in SuperSwikiServe>>entries
 
Ned also wrote:
>Bob (I think) added a shared queue into the Morphic UI process, and I added a 
>similar hook into MVC that allows objects (often blocks or message sends) to 
>be enqueued for later evaluation in the UI thread.
>
>This is used in parts of the system (look for senders of 
>addDeferredUIMessage:) that are using multitasking but still want to have 
>some UI feedback.

Aha! So then we could use this mechanism to "hand over" the actual UI updating stuff to the UI
thread when we are done? But then we have to refactor a little bit so that all those #changed:
messages are not sent all over the place... Or perhaps one could override #changed: and collect
them in order to send them all later using #addDeferredUIMessage:. Would that be "Morphishly
correct" to do?

And then you mentioned stepping as another way to do it. In this case we do not have a specific
Morph subclass but anyway, if we had that - would we then collect the #changed: calls and let the
#step method check that collection and them if there are any?

Anyway, not my intention to babble on, interesting nevertheless - it still amazes me every time
how "easy" it is to dig down in Squeak. For example, getting a profile on the
#setSelectedDirectory: method was dead simple.

My regards, Göran

=====
Göran Hultgren, goran.hultgren at bluefish.se
icq#:6136722, GSM: +46 70 3933950, http://www.bluefish.se
"Department of Redundancy department." -- ThinkGeek

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/