Scripts that are already running

[Dar Scott]

On Sep 24, 2010, at 1:38 PM, Richard Gaskin wrote:

> Jeff Massung wrote:
>
>> That said, there are areas where LiveCode could - itself - benefit  
>> from
>> multi-threading that isn't exposed to the end user. One example of  
>> this is
>> in access to the internet, file, or various OS accesses. Being  
>> able to issue
>> a large disk read/write and get a callback when done, and either a  
>> revamp or
>> serious bug fix/cleaning of libURL. Or being able to wait on a  
>> particular
>> event to be completed/happen. These alone would help considerably.
>
> One small step in that direction, from the LiveCode 4.5 Release  
> Notes.pdf (which is unfortunately buried deep inside the app bundle  
> on OS X virtually guaranteeing no Mac customer will ever see it):
>
>
>   Engine changes
>
>   Non-blocking DNS resolution
>
>   The open socket command no longer blocks on DNS resolution.
>   Instead, if resolution is required the command will return
>   immediately and the DNS lookup will happen in the background.
>   If resolution fails, then a socketError message is sent in
>   the same was as if connection fails.
>
>   For applications using hostNameToAddress directly, its syntax
>   has been augmented:
>   hostnameToAddress(hostname, [ callback ])
>   If the callback parameter is specified then the call will
>   return immediately and upon completion of the lookup, the
>   callback will be invoked with the resolved address as a
>   parameter.

This supports the event model.

In general all I/O could move to optional callbacks.  This could be  
part of unifying I/O syntax and capability.

I came from a multithreading background (and I still do that), so I  
had to shift my thinking when I caught the LiveCode train.  (It was  
newly called Revolution way back then; I was a revolutionary.)

I favor improvements that embrace event programming.  That is the  
primary way in LiveCode that multiple things get done.  However, if  
multithreading is introduced, I'd be pleased to use that as needed.   
(And kibitz as to how it is done so that all can enjoy it.)

As you mentioned:  One way to go multithreading is by  
multiprogramming.  I like that, too.

Dar Scott
... sometimes I think this code is alive ...