node-sass threadpool issue seems to still be there

[adjavaherian]

I've just pulled @latest from sass-loader and node-sass, and I'm still seeing the processor peg at 100% as noted in #100 . Should I be using a different branch as a workaround? Thanks.

[jhnns]

Mhmm the latest should be fine. Can anyone confirm this?

[adjavaherian]

I think I've been able to reproduce it on this branch. https://github.com/adjavaherian/sass-lifter-loader/tree/node-sass-threadpool-issue If you npm start the branch in the current state, the process ties up and just hangs, but if you go to index.js and change the threadpool size to 4, process.env.UV_THREADPOOL_SIZE = 4; it will compile. Conversely, if you leave the threadpool size at 5 and remove @import "./base"; from example/scss/Frontpage.scss and YetAnother.scss (there are 4 imports total), the thread will hang.

It's tricky and very well could be a something to do with the way I'm creating new webpack instances from within a webpack loader.

[jorrit]

It seems you're running webpack from within webpack. Probably some part of that causes yet another node fs-thread to block. Maybe the maximum parallellism of sass-loader should be configurable, so you can set it at UV_THREADPOOL_SIZE - 2 instead of UV_THREADPOOL_SIZE - 1.

[jcreamer898]

So I had to do process.env.UV_THREADPOOL_SIZE = 20; to get things working.

Is that the permanent fix? Still feels more like a workaround.

[jhnns]

@jcreamer898 you should not need to adjust process.env.UV_THREADPOOL_SIZE. The sass-loader is queuing its tasks so that node-sass is not blocking all threads (until node-sass has resolved this).

[jcreamer898]

Ok, I'll update to the latest and see if I can run it now without it. Thanks!

[jhnns]

Anyone still having problems?

[jhnns]

Could you guys check if the branch fix/threadpool-issue fixes this problem while using the default process.env.UV_THREADPOOL_SIZE?

[jcreamer898]

Yeah, I'll have a look.

[jcreamer898]

@jhnns I still saw the issue in that branch unfortunately. The build I'm dealing with is quite large, so I'm not surprised. It hung at ~68% for me and just got stuck.

[jcreamer898]

[jcreamer898]

Ha, I realized in my package.json I was on 2.0.1. Bumped to 3.1.1, removed the env thing, and it worked ok.

[jhnns]

That's nice 👍

Could anyone reading this issue also check out the branch? I would like to pull it on the master, but I don't have a test setup that demonstrates the problem.

[adjavaherian]

I dont seem to have this problem anymore and I'm pretty sure we're using the master branch, so not sure what happened exactly. Hopefully this doesnt cause more confusion. :) Lemme double check in a bit.

Sent from my iPony

On Oct 26, 2015, at 9:46 AM, Johannes Ewald notifications@github.com wrote:

That's nice

Could anyone reading this issue also check out the branch? I would like to pull it on the master, but I don't have a test setup that demonstrates the problem.

—
Reply to this email directly or view it on GitHub.

[adjavaherian]

Ya, I've been using 2.0.1 for a while now and not had any issues with threadpool. In fact, I don't even set the UV_THREADPOOL anymore and it seems to just work. I just tried npm installing the fix branch and it looks like there's a problem with its package.json?

//package.json
"sass-loader": "git://github.com/jtangelder/sass-loader#fix/threadpool-issue",

npm ls sass-loader
web@0.0.0 /home/adjavaherian/Desktop/web-off-master
└── sass-loader@3.1.0  invalid (git://github.com/jtangelder/sass-loader.git#d415f3fe1c8ad5e4c507fefa9f3734b4766d9d8f)