Anna Henningsen

> Although I'm not sure why the Worker::Run() isn't just doing it when I return. Because `uv_run()` doesn’t return control back to `Worker::Run()` until the thread exits, usually. > would...

> So... promises aren't queued into the loop? That’s correct – Promises are not tied to the event loop in any way. > .... is the real problem that I'm...

> a) why can't this just be a documation patch, and/or exposed as a way such that 'if your node addon does ... uv_async_whatever' you should get a deprecation mession......

> I had found this issue nodejs/node#10101 discussing the cost of MakeCallback... Keep in mind the age of that issue. A lot of work has gone into optimizing things like...

Also, if you have ideas for how to make this easier for addons, please feel free to share them, even if you’re not sure whether it’s realistic or not.

@d3x0r I haven’t forgotten about this issue, and I’ll happily re-open :) There’s definitely at least a major deficiency in our addons documentation. And, fwiw, I had that same issue...

> I still think there's no reason promises should be so special that they don't go to the run loop too. @d3x0r I’m not sure what exactly you refer to...

It sounds like you have a memory leak in your application, hence the “JavaScript heap out of memory” part. It’s hard to diagnose what that memory leak is exactly without...

JS uses floating-point numbers as its default number type, which means that large numbers will not be represented exactly. The documentation on [`Number.isSafeInteger`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isSafeInteger) has a few more details. Recent versions...

Node.js does not have any built-in support for MySQL, so it probably depends on which npm package you’re using for MySQL support?