Been off net for a while (medical issues); anyway, thought that this might be handy for you and posterity, even when it is magnificently late for the game:
I mentioned long running stuff should be 'chunked'; in the details there I mentioned that a time-based chunking approach would be best, compared to 'hardcoded number of rounds' and similar approaches, and referred to a far-from-trivial implementation. Well, here's a jsfiddle to showcase what I meant, without any clutter, not even the (STRONGLY ADVISED) used of Request.Queue: http://jsfiddle.net/uSvqz/2/ Note that the example shows how one goes about splitting a huge loop into time-delimited chunks; the trick is in wrapping it in a function (closure) and using .delay() when it's time to terminate the current run/chunk. Also note the remarks in the fiddle re order of arrival and the DoS attack. To remedy that, here's the same thing, only change being the use of Request.Queue to remove the 'similar to a DoS attack' behaviour by having the queue take care of maximizing the number of parallel outgoing requests. Also note the remarks in this one: as long as you keep that 'concurrent' number of outgoing requests down to the (default) number of 1 request-at-a-time, you get the 'guaranteed order of arrival equal to order of request set' as a nice-to-have side-benefit: see the 'text:item' numbers in the output for this one. http://jsfiddle.net/5G3hS/1/ For completeness sake, the classical approach to achieving guaranteed order of arrival in a multi-request, long running loop is shown as well: compare this to the previous two fiddles: no Request.Queue necessary (or even useful here); the loop is replaced by something that /looks/ like recursive coding. (I say /looks like/ because the onSuccess Event handler plays a major role and that one removes one of the artifacts of a recursive function: having a call stack which includes itself several times as a parent. Anyway, here it is, for reference: http://jsfiddle.net/ucrF2/1/ Maybe these can help others when they are struggling with long-running JavaScript (client-side) processes. Of course, this doesn't take away the 'rethink' admonishment regarding what one may be doing otherwise, e.g. when loading/processing a lot of data to pick only a few bits out of there: generally such filtering should be done server-side as the entire path will thus see reduced traffic and CPU load throughout. But as I said before: I'll answer this one assuming you know what you are doing. ;-) -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [email protected] mobile: +31-6-11 120 978 --------------------------------------------------
