David Bovill wrote:
> OK. A few questions... I'll post them as assertions to aid clarity.
Personally I find it clearer to read questions as questions, but with
that explanation I can work with this:
> 1. Livecode messaging is fully asynchronous. Not semi-async.
What is "semi-asynchronous" in the context of LC?
There is a distinction between "asynchronous" and "non-blocking" that
I'm not entirely clear on, so I'll use "non-blocking" for now:
Socket I/O messaging can be non-blocking when the "with <message>"
option is used, e.g.:
accept connections on port 8888 with message "GotConnection"
But this is of limited value within a single LC instance, since doing
anything with that message is likely going to involve blocking code
(e.g., reading a file or accessing a database, doing something with that
data, and then returning it).
So messages will keep coming in, but they'll queue up. This may be fine
for light loads, but when expecting multiple simultaneous connections it
would be ideal to handle the tasks more independently.
Many programs do this with threading, but we don't have threading in LC.
Instead of multithreading we can use multiprocessing, having multiple
instances of LC apps each working on a separate task.
The challenge is that to hand off a socket request to a child process
entirely would require us to have some way of handing over the socket
connection itself. I believe fork allows this, but I know of no way to
launch new instances of an LC app in a way that will hand over the
socket connection to them.
In lieu of being able to fork, two options I know of are the ones I
noted earlier; others may be possible as well, but these seem common
enough to be reasonable starting points:
<http://lists.runrev.com/pipermail/use-livecode/2015-April/213208.html>
> 2. There are a bunch of functions that are currently synchronous in
> LiveCode that make it difficult to create asynchronous code - such as
> certain network call like POST.
Yes, as above.
> 3. Livecode does not have closures = passing anonymous callbacks as
> params to functions so they can be executed later
Not per se, but as you note:
> 4. But we can easily call / dispatch calls to functions by passing
> names around and we can limit scope by using private handlers or
> libraries.
>
> Here is an article about why you should not use anonymous callbacks
> that seems interesting in the context of readabiity and literate
> programming languages:
>
> * Avoiding anonymous JavaScript functions
> http://toddmotto.com/avoiding-anonymous-javascript-functions/
Good find. While most of that is very JS-specific, the
readability/complexity argument applies in LC well. As a general rule,
I feel that "do" is a last resort when all more direct means of
accomplishing something have been exhausted, and even "dispatch",
"send", and "value" can have similar impact in terms of
debugging/maintenance.
I almost never use "do" anywhere, and on servers I limit use of the
others for another reason not mentioned in the article, security: since
they execute arbitrary code by design, "do", "dispatch", "send" and
"value" can potentially be sources of injection when used on any part of
incoming data.
I use "dispatch" in one place in my server framework, but only after
checking an incoming command argument against a list of known one-word
commands; any request missing a command parameter, or having one not
found on that list, returns an "invalid command" error message.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
