David Bovill wrote:
> - Is it worth designing a Livecode server to use asynchronous
> calls to handlers rather than normal synchronous processing?
>
> First off - the way this is going to be done will not use any io
> (file, shell or internet / socket calls) - all the data is going
> to be in memory / custom properties. This restricts the use case
> to simple sites for now - but it suits the current purpose.
...
> The question is is there any point?
Good question, because if there's no file I/O there would be no saving,
and no saving implies the data is either static or unimportant.
If static there are many good solutions for that.
If unimportant it would seem difficult to justify the R&D time.
> Firstly, because messages come into the server and are then
> immediately dispatched by the engine to event handlers
> we craft. So is this all the asynchronicity needed?
>
> Or are there some other tricks akin to the things node does if
> there are long running processes. Say there is a handler:
>
> command longRunningFibonacci someInput, someSocket
>> -- do something that takes a very long time
>> return a result
>> end longRunningFibonacci
>
>
> A browser fires off around 20 calls to the server to load a complex
> page, and they all hit at once
This is one of the nice conveniences of CGI: it lets Apache handle most
of the requests with no extra coding, since any CSS, JS, or image files
probably aren't changing for each visitor, and Apache is pretty good at
delivering static content.
And for the subset of requests that require special processing that
would need LiveCode or some other custom programming, each request
prompts Apache to create a new instance of the CGI app, providing
concurrency with no additional programming required and only a
relatively small additional cost in RAM and init time compared to system
threads.
Long processes are different, though, since they can not only result in
timeouts but also confuse the user accustomed to quick responses from
servers:
> - so is there a design consideration for any long running processes
> here - not just in terms of figure out a bette way to do it on the
> client, not with regard to the scripting of the server handler
> above?
I have a couple of workgroup apps running as CGIs, and they support a
few features which could take as long as 30 seconds if run as a single
request. I found this problematic for the user experience because we're
not giving them any feedback while it's happening (in addition to
timeouts), so I changed it to support paging.
Now the CGI includes an argument for the range of records the command
will operate on. The client first obtains the number of records from
the server, divides them by a number that means only a hundred or so
will be processed per batch, and then sends a series of requests to the
server in which each request includes the range of records to operate
on. Now the client UI has regular periodic feedback letting the user
know what's happening, and the socket never times out.
> Does the fact that the engine is dispatching calls means we can forget
> about this - or as I think is the case should I consider dispatching /
> offloading to another process this long running task, and returning
> something to the browser? If so do I keep the socket open, or ???
My understanding is that the dispatch command has no affect on blocking
vs non-blocking; it's still blocking, akin to calling a handler inline.
The "send" command can give non-blocking behavior when the "in <time>"
option is used, but for processor-intensive tasks it's of minimal value
within a single LC instance because once the handler it calls is running
all other processing stops until that handler completes.
In the absence of multithreading, this can be mitigated through
multiprocessing. The engine appears to handle socket I/O in a
non-blocking way when callbacks are used, so handing off CPU-intensive
tasks to other LC instances would seem a reasonable way to let the main
daemon focus on network I/O while leaving the heavy lifting to child
processes.
--
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
