Beyond PowerStatus: Concurrency options

[Mike Bonner]

One very simple concurrency thing I would like to see is an optional "to
thread with message" type of syntax.  This would be similar to the way
sockets are handled, if something apears in the socket, a message is
dispatched.  For things like long list processing, where the app doesn't
need to wait for completion (just an example) one could "dispatch
"doMyList" to thread with message "listDone".  It would be up to the
programmer to decide if it would work for their need, though with care, one
could selectively disable functionality while a thread was active, allowing
other parts of the application to remain functional.

I've already done similar using the load command and a local lcserver
enabled web server.  Divide up a big job into chewable pieces, off "Load"
them to the webserver, and gather/collate the results as they're returned.

On Sat, Mar 7, 2015 at 10:37 AM, Richard Gaskin <ambassador at fourthworld.com>
wrote:

> Now that members of the community have pulled together in such a stellar
> way to get a very good PowerStatus option we can use, perhaps we can go
> back to the original exploration that drove that discussion: concurrency.
>
> I first expressed a desire for a PowerStatus function in the older thread
> "Because LC can't do two things at once", at the end of this post which
> also covers some thoughts on concurrency options available to us:
> <http://lists.runrev.com/pipermail/use-livecode/2015-February/211536.html>
>
> The post also includes a link to a simple stack that demonstrates some of
> the things that made me aware of the usefulness of a PowerStatus function,
> using simple timers for background processing loops:
> <http://www.fourthworld.net/channels/lc/IdleHour.rev>
>
> If exploring concurrency options is of interest here, we might consider
> two categories of such things:
>
> - A) Stuff we can do now with what we have (mostly timers and/or
>      multiple faceless LC instances as worker processes)
>
> - B) Stuff we could do if only we had X (where X is what we'd need
>      to define)
>
> Is concurrency something we want to pursue for LiveCode?
>
> What can we do now, and what would we like for the future?
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>