nex3
commented
2 years ago This is an unfortunate side-effect of the way Dart handles the intersection of synchrony and asynchrony. In order to call an asynchronous custom function from a synchronous compilation process, we need to use Dart's waitFor(Future) function which runs another event loop on top of the current stack. This means that if you pile up too many asynchronous operations all at once, you can end up with a stack overflow.
Unfortunately, Dart doesn't have any other mechanism for forcing synchrony. The only alternatives I see are:
- Run the entire compiler in asynchronous mode, which is much less performant.
- Run each instance of the compiler in a separate isolate, which eliminates most of the benefits of sharing a process in the first place and precludes the possibility of sharing any state across compilations.
- Beg the Dart core library team for better synchronization APIs, which has not historically been very successful (they already hate
waitFor()). - Introduce some kind of rate-limiting isolate that holds back requests to ensure that only N are active at once, which is probably the most promising option but will increase the process's startup time and so probably shouldn't be done until https://github.com/sass/sass/issues/3296 is in place to avoid regressing performance for the JS package.
ntkme
The dart-sass-embedded compiler would stack overflow with lots of concurrent requests.
This issue cannot be reproduced with the sass-embedded npm package because the node host does not re-use the compiler, but on the ruby host I can reliably reproduce it: