3 ms·
Deep diving into the thread pool: a debugging story
- realitysballs 5y agoThat bug went deep . The catharsis is palpable
- kevingadd 5y agoHaving worked on lots of games and web frontend stuff, the idea of happily blocking the event loop for 5 whole seconds in order to avoid paying some signaling/synchronization overhead kind of blows my mind. It seems so blatantly inappropriate to block the event loop in an environment like node where the whole platform is built around the assumption that progress will not occur unless the event loop is pumping. Certainly if doing synchronization and signaling correctly produces a 27% performance hit (????!!! how) then it makes sense to try and mitigate that, but all of this makes alarm bells go off for me about some sort of fundamental architecture problem they're going to get ambushed by later on.
- yakkomajuri 5y agoThis is a valid concern. I think it's just worth noting a few things: - Piscina will block the worker event loop indefinitely by default. This is their way of circumventing the native port.on('message', callback) API. It definitely shocked me a bit at first, but the team's maintainers include maintainers of Node itself (so this likely wasn't a beginner's mistake), and the decision makes sense given the scope of the project. - We use Piscina in a way that's very custom to our needs, hence we've forked it. The solution here was one that both fit us very well and was quick to implement, which is why we picked it. We did also expose the useAtomics flag on our side, so it's possible to turn off all event loop blocking at the worker level very easily.
- twhitmore 5y agoYou might want to ask yourself some questions about the technology platform you're building on.