The main reason for doing things asynchronously are 1) to improve performance in a high-transaction environment 2) keep collisions to a minimum.
In your case, it does not appear that either is going to happen, so I wouldn't bother. On Mon, Jul 20, 2015 at 12:03 PM, Richard Gaskin <ambassa...@fourthworld.com > wrote: > 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 > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." _______________________________________________ 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