Sami Vaarala

Hmm, somewhat related, dense arrays are relatively memory efficient to represent tagged value slices. The cost is a `duk_harray` header but after that there's no additional overhead because a dense...

I don't really see that as a black-and-white issue either way. It's about trade-offs between performance, scheduler flexibility, and error proneness. It's quite possible to design an API where the...

Right, non-determinism is a "cost" you need to pay if you want to optimize performance _and_ give the scheduler the power to decide how many inline calls are made in...

Once the 2.1.0 release is complete I'll try to write a first draft of a job queue implementation which could then be used as a basis for starting a Promise...

Regarding the C API, not sure if it was covered earlier but: the `duk_debugger_cooperate()` is typically called from an event loop with the call stack empty, so it'd actually be...

The duk_debugger_cooperate() call is actually missing a true/false return value (indication of whether there are potentially more commands). It doesn't matter if one calls the function constantly, like in the...

Fairness is a very difficult issue with job queues in general. As an initial implementation I'd probably want to go with a single FIFO which is at least easily understandable....

But in case it's also a practical issue, maybe it would suffice to use a simple rate limiting mechanism to cap the rate of messages processed in a non-paused state....

As discussed above, I'm not entirely happy with the basic queue-job/process-job design because it needs application co-operation. In particular, if an application uses Promises but doesn't call `duk_process_job()` or whatever,...

I haven't read through it all in detail but I'd be surprised if it did, other than saying they should execute from an "empty call stack" (and maybe "without delay",...