Hi!

--- J Scott Jaderholm <scott at jaderholm.com> wrote:
> Hi,
> 
> When I click FIND and then Bob's SuperSwiki it normally takes about 10
> seconds or so to lookup the listing of projects.  During this time the
> whole rest of the Squeak process stalls up and I can't do things in
> other windows etc.
> 
> I bring this situation up because it's pretty much the only thing that
> takes long enough in squeak that I'd like to be doing something else.
> 
> I'm curious though, is it only my linux box that is doing this because
> the linux VM doesn't have multithreading for squeak or is it squeak in
> general.  If it is linux, how do I fix it?  If it is squeak in

Ok, I might be slightly mistaken here, but anyway:

It has nothing to do with the VM or OS, AFAIK, Squeak's "multithreading" is done "in Squeak" so to
speak. Take a look at classes Process and ProcessorScheduler for more info.

The simplest way of starting another thread of execution in Squeak is by using the message "fork"
with a block like this:

[ Transcript show: 1000 factorial ] fork

This would start off the block of Squeak code computing the factorial in another "thread" or so
called Squeak Process. Actually, this version would be even better to try in a Workspace:

[ Transcript show: 1000 factorial ] forkAt: Processor userBackgroundPriority

...since it would put the process at a more suitable priority. Open up a transcript, select this
code in a workspace and "do it", then do something with Squeak during the computation and notice
how the answer suddenly pops up in the transcript. Nice!

Now, let's see if we can "hack" your specific problem, I opened up the filelist and selected the
SuperSwiki and when the cursor sleeps I pressed Alt-. (on my Win98 machine) and opened the
debugger. Studying the stack in the debugger lets us find out some stuff:

It looks like some morph calls Filelist2>>setSelectedDirectoryTo: which in turn calls
CursorWithMask(Cursor)>>showWhile:. This is the method that turns the Cursor into the "sleeping"
symbol. And then we can see further up that the SuperSwikiServer uses an HTTPSocket to retrieve
the information to list which probably is the thing that takes some time.

Ok, so if we could "fork off" the stuff that happens in setSelectedDirectoryTo: then perhaps we
would not have to wait. So we change the method from looking like this:

-----------
setSelectedDirectoryTo: aFileDirectoryWrapper

self directory: aFileDirectoryWrapper withoutListWrapper.
brevityState := #FileList.
"self addPath: path."
self changed: #fileList.
self changed: #contents.
self changed: #getSelectedDirectory.
------------

to this:

-----------
setSelectedDirectoryTo: aFileDirectoryWrapper

[ 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.

Voilá! It does not block while fetching the list!
Hopefully this little hack worked for you too... :-) :-)

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/