tools: run tick processor without forking #4224
Conversation
| fs.writeFileSync(tempNm, process.binding('natives')['v8/tools/mac-nm'], | ||
| { mode: 0o555 }); | ||
| tickArguments.push('--mac', '--nm=' + path.join(process.cwd(), tempNm)); | ||
| var nm = 'foo() { nm "$@" | (c++filt -p -i || cat) }; foo'; |
There was a problem hiding this comment.
I've converted as many of the vars in the polyfill and processor to const as I could. Unfortunately, the lack of strict mode prevents the use of let (not sure why const is allowed outside of strict now that I think about it).
There was a problem hiding this comment.
Hm, if we are not in strict mode, shouldn't we use var instead. Sloppy mode const is totally different IIRC
There was a problem hiding this comment.
The script appears to behave correctly using either const or var and I am unfamiliar with how things operate outside of strict mode. Happy to switch back to var if that is preferred.
|
Thank you for your update, CI : https://ci.nodejs.org/job/node-test-pull-request/973/ |
| return require('child_process').execFileSync( | ||
| name, args, {encoding: 'utf8'}); | ||
| const cmd = name + ' ' + args.join(' '); | ||
| return cp.execSync(cmd, {encoding: 'utf8'}); |
There was a problem hiding this comment.
Maybe use .spawnSync() here? You can pass it arguments as an array and it will take care of shell escaping them.
There was a problem hiding this comment.
When I use spawnSync, I get the error Error: spawnSync foo() { nm "$@" | (c++filt -p -i || cat) }; foo ENOENT. I'm not sure exactly how spawnSync and execSync differ but they're not handling this command the same way.
There was a problem hiding this comment.
.execSync() executes the command as /bin/sh -c '<cmd> <args>' (cmd.exe /s /c "<cmd> <args>" on Windows) whereas .spawnSync() simply calls execve(). Guess I was wrong saying it takes care of shell escaping because it doesn't need to escape anything.
You could wrap that bit of shell script in a sh -c or bash -c below. Longer term, it might be nice to move normalizeExecArgs() from lib/child_process.js to lib/internal/child_process.js so you can use it here. It's possible some more work needs to be done on the internal module system to make that work, though.
I'll leave it up to you if you want to change this line.
There was a problem hiding this comment.
I don't believe wrapping it in sh -c or bash -c will work in this instance because the shell script defines a function and then calls it on arguments that will be provided later at the call site. This is the snippet in question:
foo() { nm "$@" | (c++filt -p -i || cat) }; fooLater it will be invoked as:
foo() { nm "$@" | (c++filt -p -i || cat) }; foo -n -f /usr/lib/system/example.dylibIs it possible to perform that wrapping you described in this case?
There was a problem hiding this comment.
sh -c 'foo() { ... }; foo $@' -- should work, if I understand you right.
There was a problem hiding this comment.
I have this working now. Will spawning /bin/sh work correctly on windows or does that need to be special cased?
There was a problem hiding this comment.
On Windows there is no /bin/sh, you'd use cmd.exe /s /c, but I don't think you actually need to spawn a shell. The OS X case is special because you're executing shell script, on other platforms nm is invoked directly.
There was a problem hiding this comment.
I can handle the OS X case specially here if that is preferable. What is the motivation of changing execSync to spawnSync?
There was a problem hiding this comment.
That you won't have to worry about escaping spaces in paths, for example.
There was a problem hiding this comment.
Ok, that makes sense, I've added the special casing here and it's working on my test machine (OS X).
|
LGTM with a suggestion. |
|
LGTM |
Using the tick processor no longer creates temporary files or spawns a child process.
Using the tick processor no longer creates temporary files or spawns a child process. PR-URL: #4224 Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]> Reviewed-By: jasnell - James M Snell <[email protected]>
|
Thanks. Landed on |
Using the tick processor no longer creates temporary files or spawns a child process. PR-URL: nodejs#4224 Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]> Reviewed-By: jasnell - James M Snell <[email protected]>
|
@jasnell should this go to LTS? |
|
relies on #4021 |
Using the tick processor no longer creates temporary files or spawns a child process. PR-URL: nodejs#4224 Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]> Reviewed-By: jasnell - James M Snell <[email protected]>
Using the tick processor no longer creates temporary files or spawns a child process. PR-URL: #4224 Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]> Reviewed-By: jasnell - James M Snell <[email protected]>
Using the tick processor no longer creates temporary files or spawns a child process. PR-URL: #4224 Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]> Reviewed-By: jasnell - James M Snell <[email protected]>
Using the tick processor no longer creates temporary files or spawns a child process. PR-URL: nodejs#4224 Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]> Reviewed-By: jasnell - James M Snell <[email protected]>
Using the tick processor no longer creates temporary files or spawns a
child process.
/cc @bnoordhuis