Re: Re: Simultaneous Events (in AS CGI's)
Re: Re: Simultaneous Events (in AS CGI's)
- Subject: Re: Re: Simultaneous Events (in AS CGI's)
- From: email@hidden
- Date: Fri, 20 Apr 2001 16:27:01 EDT
Cris and Simon,
I used to think Applescript used a pure LIFO model, but my most recent
testing tells me it is much more complex (confused?) than that.
This was all done with MacOS 9.1 and Applescript 1.6.
<eye glaze>
Save this script as a stay open applet with the name "doThings"
-------------------------
property logger : {}
on doThing1(x)
copy ("" & x & "p") to end of logger
set t0 to the ticks
set t1 to the ticks
-- simulate a time consuming task
repeat until t1 - t0 > 120
set t1 to the ticks
end repeat
copy x to end of logger
end doThing1
on handle CGI request with posted data x
copy ("" & x & "p") to end of logger
set t0 to the ticks
set t1 to the ticks
-- simulate a time consuming task
repeat until t1 - t0 > 120
set t1 to the ticks
end repeat
copy x to end of logger
end handle CGI request
on getLogger()
return logger
end getLogger
on resetLogger()
set logger to {}
end resetLogger
-----------------
Put this script into Script Editor.
--------------------
set t to the ticks
log t
repeat with i from 1 to 9
tell application "doThings"
ignoring application responses
handle CGI request with posted data (i as string)
doThing1(i + 10)
-- delay 1 -- another variation to try
end ignoring
end tell
end repeat
repeat 4 times
set x to {}
tell application "doThings"
with timeout of 1 second -- seems to ignore this
try
set x to getLogger()
on error --
end try
end timeout
try
log x
on error
log "no x yet"
end try
set t to the ticks
log t
end tell
delay 1
end repeat
tell application "doThings"
resetLogger()
end tell
--------------------
Open the Event Log window. Select "Show Events" and "Show Event Results."
With doThings NOT YET running, run the second script. Study the output. Looks
like LIFO, right? (BTW, on my machine event #2 seems to get lost - not good.)
Leave doThings running. Run script #2 again. Now it looks like FIFO. Study
the value for the ticks (Jon's Commands 2.1.2). Correlate the values with the
pause you experienced. Makes sense?
Look at the values returned from getLogger. If you run the script several
times, you will likely see a value of logger which suggests that not all
calls to doThing1() have completed. Hmmm.... in what order does that suggest
they are executing?
Quit doThings. Run script 2 again. Look again at the ticks. The timing gap
does not make sense.
If you're feeling particularly geekish, comment out the calls to doThing1()
or handle CGI request. Run again, both with doThings already running and not
running.
</eye glaze>
I have been saying for years that I would really like Applescript to have
full multithreading. I'm not sure we are there, and based on my testing, I'm
really not sure where we are. Next time I boot into OSX I'll try these
scripts again.
Jeff Baumann
email@hidden
www.linkedresources.com
>
on 19.04.2001 11:33 Uhr, Simon Forster at email@hidden wrote:
>
>
> In the last couple of days there have been at least 2 posts asking how
>
> AppleScript applications and/or AppleEvents handle simultaneous events. I'd
>
> like to know this too.
>
>
>
> For my part, I wrote an AppleScript CGI which would "email this web page to
>
> a friend". It worked fine except, if the CGI was handling a request,
>
> subsequent requests seemed to be ignored until the current task had been
>
> completed. How to work around this?
>
>
>
> I imagine that each event should instantiate a new AppleScript object -
>
> although whether this is possible in AppleScript and how one does this is
>
> unclear to me at this point in time.
>
>
>
> Any pointers to understanding how AppleScript can handle simultaneous
events
>
> would be appreciated.
And in a message dated 4/20/01 11:14:04 AM, cris responded:
>
AppleScript CGI's are based on a LIFO (last in first out) concept. Your
>
observation is wrong, subsequent requests are executed immediately, which is
>
a real problem if the cgi get's more traffic than it can actual handle. In
>
such a situation nobody get's an answer from the script. A FIFO based cgi
>
would at least serve it's maximum it can handle.
>
>
Furthermore LIFO means you have to be very careful with variables declared
>
as globals. Use globals only for variables that never change their values
>
during the script is working.
>
The values of local variables are always held when a subsequent request
>
interrupts the current script run. A global variable will be overridden by
>
the subsequent request, meaning that the earlier request will continue it's
>
work with wrong variable values when the subsequent request has finished.