Re: Script Applet rejects first handler call
Re: Script Applet rejects first handler call
- Subject: Re: Script Applet rejects first handler call
- From: email@hidden
- Date: Tue, 31 Jul 2001 19:44:20 -0400
On Tue, 31 Jul 2001 12:19:41 -0400,
Paul Skinner <email@hidden> suggested,
>
> [...] When I call a handler in a script applet from
>
> another script, I get an error on the first call.
>
I see this as normal behavior. I had no idea that it ever worked
>
differently.
I'd done extensive experimentation with AppleScript 1.3.7 and earlier, and found
that if you just say,
tell application "My Server" to foo(x,y,z)
Everything worked as expected, documented, and as was convenient. If the app
wasn't running, your script sent it a "run" event, and when that returned, it
sent the event to invoke the handler.
I did find some unexpected and inconvenient behavior if you launched the
application, or if you asked it for the value of a property. Specifically,
those two actions would start the idle handler running before the run handler.
So you couldn't count on the run handler to initialize things.
I think that there also was a change in behavior in a multitasking scenario
somewhere between 1.3.7 and 1.5.5. Early versions blocked entirely, so if two
scripts sent events, it was first come, first served, and no simultaneous
processing. But afterwards, there seemed to be one level of reentrancy. So
script A could send an event which would start processing, script B could send
one, which would interrupt the processing of A, but if script C sent an event,
it would block. It was somewhat hard to test, but I never could succeed at
using a Facespan application as a useful control panel for a separate script
server application.
I've just rerun my tests under AppleScript 1.5.5 (but with scripts compiled by
Script Editor 1.6. The applet shell may be coming from Script Editor and not
AppleScript). I ran a server and three clients, and found that the clients
could each reenter the same handler in the server, interrupting each other. So,
I could get a trace that looks like this:
Entering Run handler
> Entering handler for client 1
-> Entering handler for client 2
--> Entering handler for client 3
<-- Leaving handler for client 3
<- Leaving handler for client 2
< Leaving handler for client 1
Leaving Run handler
Entering idle handler
> Entering handler for client 1
-> Entering handler for client 2
--> Entering handler for client 3
<-- Leaving handler for client 3
<- Leaving handler for client 2
< Leaving handler for client 1
Leaving idle handler
This is troubling because AppleScript has no guaranteed way to atomically test
and set a semaphore, so we can't be sure that we won't have problems with
multiple clients accessing the same data.
Maybe you can test and set a semaphore with a list assignment:
set {success, lock} to {(lock is false), true}
This assumes that the calculation of (lock is false) and the assignment of lock
to true won't be split apart by some other client calling the server's handler.
That'll be a test for later.
>
In my experience the Until the server script is run it can't server it's
>
handlers. The first call to the script server finds it inactive and causes
>
it to run. But the call is lost. I avoid the issue by calling a property of
>
the server script at the top of the script which wants to use the server
>
scripts handlers. If you wrap this call in a try within a repeat until loop
>
then the first call launches the server script and the subsequent calls fail
>
until the script server is initialized. Then it works. With your example you
>
could do something like...
Basically, I think this approach is just coding around the error. You can
explicitly run the server, or you can catch the error that occurs and keep
poking at it until it succeeds. People already do similar things with files
that are busy, after telling the Finder to copy them.
Unfortunately, I can't use this approach when the script is being invoked by
something that I didn't write. Specifically, when ListSTAR is calling a script
action, or when a web server is calling a CGI script.
Something seemed to happen involving dynamic terminology in AppleScript 1.6.
When I compile a script with a
tell application "My server script"
block in it, it launches the target application. That's different than the old
behavior. Maybe they are getting ready for dynamic terminology, like the MRJ
Java runtime applet does.
Oddly, this only happens when the applet is referred to after the first time it
is saved. Subsequent edits and saves of the server don't require it to be
started when any of its clients are compiled. I suspect many users will be
perplexed at this behavior, but when it doesn't recur, dismiss it as a visit by
gremlins.
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden