Rev performance: help! (solved)
dcragg at lacscentre.co.uk
Thu Dec 8 03:29:56 EST 2005
On 7 Dec 2005, at 15:23, Jon Seymour wrote:
> Thanks again to Dave for insisting that I must have had a libURL
> call in there somewhere :)
Although we solved Jon's immediate problem (wrong url), I think there
must have been something else going on to produce the results he
One possible suspect was the use of a "wait ... with messages"
statement while a url was still loading. Although we never confirmed
this, it's probably worth mentioning this potential gotcha. (Brought
to my attention recently by Chipp Walters.)
libUrl uses the "wait for messages" statement to implement it's
asynchronous behavior, in a "wait" loop something like this:
repeat until <some condition>
wait for messages
This is equivalent to:
wait until <some condition> with messages
If you later use another "wait ... with messages" statement while the
earlier one is still "waiting", the earlier "wait" will remain stuck
while the later one is waiting, even if its condition has been met.
The following script illustrates this, where handler_one won't
complete until handler_two completes.
put false into gDone
send handler_two to me in 10 milliseconds
wait until gDone = true with messages
put "handler_one finished" & cr after field 1
put "handler_two stage 1" & cr after field 1
put true into gDone
wait 2 seconds with messages
put "handler_two stage 2" & cr after field 1
The upshot of this is that if you use load, then have a wait
statement like this:
load url myUrl
wait unitl <some condition> with messages
the "load url" won't complete until <some condiion> is met. If <some
condition> takes a long time to be satisfied, the "load" will take
that long as well.
This is a potential problem with "black box" scripted libraries such
as libUrl which are implementing asynchronous behavior.
You can use the waitDepth function to see if there are any
outstanding waits. But avoid the temptation to do something like
"wait until the waitdepth is 1 with messages", which immediately
causes the problem. Be careful! (But not too careful. :-))
Judy, if you're reading, I wonder if this kind of thing may have had
something to do with what you were seeing.
More information about the Use-livecode