diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/api/child_process.markdown | 8 | ||||
| -rw-r--r-- | doc/api/process.markdown | 14 | ||||
| -rw-r--r-- | doc/blog/nodejs-road-ahead.md | 52 |
3 files changed, 67 insertions, 7 deletions
diff --git a/doc/api/child_process.markdown b/doc/api/child_process.markdown index 6a11edebb..0f0e463b5 100644 --- a/doc/api/child_process.markdown +++ b/doc/api/child_process.markdown @@ -535,7 +535,7 @@ amount of data allowed on stdout or stderr - if this value is exceeded then the child process is killed. -## child_process.execFile(file, args, options, callback) +## child_process.execFile(file, [args], [options], [callback]) * `file` {String} The filename of the program to run * `args` {Array} List of string arguments @@ -568,8 +568,10 @@ leaner than `child_process.exec`. It has the same options. * `execPath` {String} Executable used to create the child process * `execArgv` {Array} List of string arguments passed to the executable (Default: `process.execArgv`) - * `silent` {Boolean} If true, prevent stdout and stderr in the spawned node - process from being associated with the parent's (default is false) + * `silent` {Boolean} If true, stdin, stdout, and stderr of the child will be + piped to the parent, otherwise they will be inherited from the parent, see + the "pipe" and "inherit" options for `spawn()`'s `stdio` for more details + (default is false) * Return: ChildProcess object This is a special case of the `spawn()` functionality for spawning Node diff --git a/doc/api/process.markdown b/doc/api/process.markdown index c68b5f9d5..18cdb5a8d 100644 --- a/doc/api/process.markdown +++ b/doc/api/process.markdown @@ -140,9 +140,9 @@ Note: `SIGHUP` is to terminate node, but once a listener has been installed its default behaviour will be removed. - `SIGTERM` is not supported on Windows, it can be listened on. -- `SIGINT` is supported on all platforms, and can usually be generated with - `CTRL+C` (though this may be configurable). It is not generated when terminal - raw mode is enabled. +- `SIGINT` from the terminal is supported on all platforms, and can usually be + generated with `CTRL+C` (though this may be configurable). It is not generated + when terminal raw mode is enabled. - `SIGBREAK` is delivered on Windows when `CTRL+BREAK` is pressed, on non-Windows platforms it can be listened on, but there is no way to send or generate it. - `SIGWINCH` is delivered when the console has been resized. On Windows, this will @@ -152,6 +152,12 @@ Note: node on all platforms. - `SIGSTOP` cannot have a listener installed. +Note that Windows does not support sending Signals, but node offers some +emulation with `process.kill()`, and `child_process.kill()`: +- Sending signal `0` can be used to search for the existence of a process +- Sending `SIGINT`, `SIGTERM`, and `SIGKILL` cause the unconditional exit of the + target process. + ## process.stdout A `Writable Stream` to `stdout`. @@ -483,7 +489,7 @@ An example of the possible output looks like: Send a signal to a process. `pid` is the process id and `signal` is the string describing the signal to send. Signal names are strings like 'SIGINT' or 'SIGHUP'. If omitted, the signal will be 'SIGTERM'. -See kill(2) for more information. +See [Signal Events](#process_signal_events) and kill(2) for more information. Will throw an error if target does not exist, and as a special case, a signal of `0` can be used to test for the existence of a process. diff --git a/doc/blog/nodejs-road-ahead.md b/doc/blog/nodejs-road-ahead.md new file mode 100644 index 000000000..568530f21 --- /dev/null +++ b/doc/blog/nodejs-road-ahead.md @@ -0,0 +1,52 @@ +title: Node.js and the Road Ahead +date: Thu Jan 16 15:00:00 PST 2014 +author: Timothy J Fontaine +slug: nodejs-road-ahead + +As the new project lead for Node.js I am excited for our future, and want to +give you an update on where we are. + +One of Node's major goals is to provide a small core, one that provides the +right amount of surface area for consumers to achieve and innovate, without +Node itself getting in the way. That ethos is alive and well, we're going to +continue to provide a small, simple, and stable set of APIs that facilitate the +amazing uses the community finds for Node. We're going to keep providing +backward compatible APIs, so code you write today will continue to work on +future versions of Node. And of course, performance tuning and bug fixing will +always be an important part of every release cycle. + +The release of Node v0.12 is imminent, and a lot of significant work has gone +into this release. There's streams3, a better keep alive agent for http, the vm +module is now based on contextify, and significant performance work done in +core features (Buffers, TLS, streams). We have a few APIs that are still being +ironed out before we can feature freeze and branch (execSync, AsyncListeners, +user definable instrumentation). We are definitely in the home stretch. + +But Node is far from done. In the short term there will be new releases of v8 +that we'll need to track, as well as integrating the new ABI stable C module +interface. There are interesting language features that we can use to extend +Node APIs (extend not replace). We need to write more tooling, we need to +expose more interfaces to further enable innovation. We can explore +functionality to embed Node in your existing project. + +The list can go on and on. Yet, Node is larger than the software itself. Node +is also the community, the businesses, the ecosystems, and their related +events. With that in mind there are things we can work to improve. + +The core team will be improving its procedures such that we can quickly and +efficiently communicate with you. We want to provide high quality and timely +responses to issues, describe our development roadmap, as well as provide our +progress during each release cycle. We know you're interested in our plans for +Node, and it's important we're able to provide that information. Communication +should be bidirectional: we want to continue to receive feedback about how +you're using Node, and what your pain points are. + +After the release of v0.12 we will facilitate the community to contribute and +curate content for nodejs.org. Allowing the community to continue to invest in +Node will ensure nodejs.org is an excellent starting point and the primary +resource for tutorials, documentation, and materials regarding Node. We have an +awesome and engaged community, and they're paramount to our success. + +I'm excited for Node's future, to see new and interesting use cases, and to +continue to help businesses scale and innovate with Node. We have a lot we can +accomplish together, and I look forward to seeing those results. |