Scripts that are already running

[Richard Gaskin]

DunbarX wrote:

> This all came about because someone wanted a single universal watchdog on
> his stack. He had several handlers in several places, all of which could
> create a condition he wanted to act upon. So the "send in time" handler fit that
> bill. If he created yet another such handler somewhere, it would be
> covered. But it occurred to be that if the condition was met and the handler still
> had much to do and might take a long time to do it, then the condition could
> not be dealt with until that handler ends. It seemed intriguing to think
> that something could monitor, say, the state of variables, from outside the
> handler while it was running.
>
> Anyone think this is a useful, perhaps monumental, feature?

Indeed it would:

Add Threaded messaging and or execution in Transcript
<http://quality.runrev.com/qacenter/show_bug.cgi?id=2832>

But threading comes with an additional level of responsibility.  Right 
now we almost never have to worry about race conditions, an area where a 
lot of programmers using threaded languages spend thousands of hours 
each year debugging hard-to-track-down issues.

Once you introduce threading into the language it's like handing someone 
a loaded gun with a map to their foot.  Still very useful, and well 
worth implementing, but it would so fundamentally change the messaging 
system that it would raise the learning curve and open up many new ways 
to make mistakes. :)

For those who need it threading would be a godsend, and RunRev couldn't 
add this fast enough for me.  Many server processes could be much more 
optimized with a threaded implementation.

In the meantime, for single-user apps working within a non-threading 
system isn't usually so bad.  As we've seen in this example, it usually 
requires no more than a single line of code to have any additional 
checking happening inside of any handler you like, and with that 
requirement it leaves the scripter explicitly in control of the 
interactions between things.

For property settings this might even be reduced to zero additional 
lines of code in the repeat loop if you include a setProp handler that 
will respond to the change:

-- Main handler:

on mouseUp
   repeat with i = 1 to 100
      set the uMyProp of this stack to i
   end repeat
end mouseUp


-- In stack script, library, or any other place in the
-- message path:

setProp uMyProp pValue
   if pValue = 50 then
     DoSomethingCool
   end if
end uMyProp


It can be tempting to use getProp and setProp in places where more 
controllable and concise function and command calls can work well as 
accessors, but when you need 'em they're handy to have available.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv