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 ...
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
