Scripts that are already running

[zryip theSlug]

On Fri, Sep 24, 2010 at 8:12 PM, Richard Gaskin
<ambassador at fourthworld.com> wrote:
> 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.

Threading is cool. But it depends of your needs.
During more than 10 years I'm doing development and excepted specifics
needs, the only need I have with thread is have a thread which sleep
for an amount of time and wakeup to perform an action. In one hour,
one day...
In fact, nothing more than the send in time in LiveCode can do. And
more elegantly.

-- 
-Zryip TheSlug- wish you the best! 8)
http://www.aslugontheroad.co.cc