Bruce Pascoe

It seems we were actually on the same page all along and just didn't know it :)

Oh, by that I meant the contrived example itself exactly as described. If the Ecmascript function did something more substantial than just immediately calling the C function you passed it...

But yeah, I understand what you're saying: The infrastructure itself may be written in JS in which case an empty callstack is impossible. I have no problem with that.

That throwing behavior would make it impossible for me to use Duktape Promises in minisphere, so I'd prefer if it were optional if anything.

> Regarding implementation it'd probably be good to add generic support for a job queue into the C API first, and then implement Promises on top of that. :+1: to...

> It can then be improved later by maintaining a "next" index and only really unshifting the queue occasionally. Another option would be a circular queue with a "next" index....

I found this article that explains pretty well why Promises are never settled synchronously: http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony Quite an interesting read. "Releasing Zalgo" indeed. :)

Regarding mixing inline with async, the article above links to the following article which talks about that too: https://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/ The gist is that, if you have scenarios where sometimes you...

Back on topic: Having quickly revisited my Promises branch, I agree that it'd be better to implement that generic job queue support first, before moving forward with a Promise implementation.

This seems workable. One thing that worries me though is the possibility that under heavy debugger activity the debugger may starve the real job queues and therefore make it more...