-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Render with custom import hangs #857
Comments
/cc @saper (you seem to know your way around this area) 😄 |
I think I have it identified. Workaround: |
Nice, I'll dig into it. I've just started reading the node addon docs :) |
Looks like that's the legit solution haha nice one. Ideally we could catch when the queue was full and handle it more gracefully. |
I have a fix in my head just need to go via the usual write-compile-test-repeat cycle :) |
I'd love to see it. I've been reading over the relevant docs but I can't a way to increase the thread pool during execution or stop the queue from being flooded. |
This seems to suggest it can be done in runtime if it's early enough joyent/libuv#649 (comment) |
this is a bug. it just explains why 4 (the default) seems to the magic number. |
I've seen suggestions that this does not work reliably on Windows. It will require some further investigation but atm it blocks custom importers with |
Given the state of things I consider going back to 2.1.1 code base.... There are some inherent issues in the callback bridge that do not seem easy to solve (for example we call v8 functions and alter its state in new threads). just tried 2.1.1 - it hangs the same way as well, because it exhausts uv thread pool the same way. |
I currently see two solutions:
|
Wouldn't it be easier to just queue the work load? Wouldn't any other implementation need a queue too at some point? IMO you will run out of cpus and other resources anyway at some point. I really have only an overview of what you are doing in node-sass by glancing over the issues from time to time. But given the problem as far as I understand it, I would try that approach first. If I'm correct you already have a limited amount of threads available to dispatch work to, so this model should fit very well? |
We are queuing the rendering requests nicely in the thread pool maintained by the Here's what happens as I understand it:
Solutions: A) It would be cool to be able to tell B) I could use libcoro or some other clever hack to postpone execution of the libsass rendering thread - move aside current the C stack and quit my worker thread. When the user importer is read, a callback handler would restore libsass C stack and pretend nothing happened (and use C) A rendering worker thread, instead of sleeping and waiting for JavaScript to continue it could yield its time slices to execute other code - node has a process.nexttick facility for that. Unfortunately, since node is (almost) single-threaded, I cannot wake up node's execution queue from another, non-node thread. D) Another solution would be to have our own private thread pool (that's libuv/libuv#267), not to conflict with filesystem thread pool. E) Create our own one worker thread that communicates two-way with the user custom function/importing code on one side and libsass on the other (what I drafted in sass/libsass#1108). We can use a pipe or sockets to communicate without using locks. This is a variant of (B), but implemented with pipes and not C library calls and does not require me to change libsass at all; I only would love to be able to send (transparently) some libsass internal structures (like |
Moving this to v3.next because
|
To be honest, I haven't understand the problem completely. 😀 But would it be possible to add a quickfix for this in sass-loader? Like limiting I/O operations to one at a time? |
No, there is no quick fix. unless when you pre-load your files or something like that. Or sync. |
@jhnns there's not quick fix we can implement. However you can set the follow the Some projects max this out on load (mapbox/mapbox-studio-classic@c9cda61). This will technically work around the problem, but it'll allow the node process to consume a lot of resources |
Is there any progress on this, or otherwise a way to show a message that there is a deadlock? |
Unfortunately a dead lock, prevents us doing anything. |
Not even starting a watchdog thread before the other threads, which warns On Wed, Jan 20, 2016, 11:05 AM Michael Mifsud [email protected]
Wout. |
PRs welcome
|
Folk affected by this bug are free to try #1112 (it probably needs to be rebased on top of the current code though). |
reverted the node-sass version due to sass/node-sass#857
Given the following
fs.readFile
never executes it's callback and process hang indefinitely.// _partial.scss foo{}
Outputs this and hangs
This example works fine if:
renderSync
fs.readFileSync
This is potentially related to #794.
This issue has been reproduced on multiple OSX machines on the latest node 0.10, 0.12 and iojs with [email protected]
The text was updated successfully, but these errors were encountered: