HTML5 update: why it is slow?

Monte Goulding monte at
Fri Jan 8 21:56:20 CET 2016

> On 9 Jan 2016, at 2:20 am, Trevor DeVore <lists at> wrote:
>  start asynchronous block "processThing" with error callback

Background threads then. A while back we were discussing threading ( <>) and I proposed:

> How about there's two standard queues (foreground, background) with the ability to create more as required. A queue would have a thread and it's own pending messages with engine messages going to the foreground queue.
> Maybe:
> create queue <queue name>
> dispatch <commandName> to <objectReference> [with param1… n] [[in {foreground|background|<queue name>}] with message <callback>]
> delete queue <queue name>
> A queue might have it's own instance of the handlers to message but perhaps we would need a sort of common script local which would be accessible from all threads and a regular script local which isn't. In most cases there would be no need to create a named queue but it might be helpful in some cases.

However, I don’t think background threads will actually resolve the issue at hand because we still have the blocking commands and waits but they are just on a different thread.

One thing that might work to avoid having multiple callbacks would be completion handler style blocks. This would be particularly helpful if their variable scope included the locals in the parent handler. This would also give us the choice of declaring a callback either inside or outside the current handler.

Using Mark’s example:

on processThing
 load url "..." with block pResultCode, pData, pError
 end block
end processThing

— OR

on processThing
 load url "..." with processThing2
end processThing

block processThing2 pResultCode, pData, pError
end processThing2

Whether it would be feasible to mix in the queue idea with blocks for running scripts asynchronously I’m not sure but it’s probably a neater idea than my dispatch butchery. We would just need something like:

do processThing2 in background with tResultCode, tData, tError



More information about the use-livecode mailing list