Node v0.8 roadmap
-----------------
- Move the remaining platform functions from src/platform-*.cc into
libuv. (Everyone)
https://github.com/joyent/node/issues/2132
- Get rid of WAF. All platforms will build using GYP. (Ben, Ryan)
https://github.com/joyent/node/issues?labels=gyp&sort=created&direction=desc&state=open&page=1
- Isolates. Node will allow users to spawn "child processes" that actually
run in a thread. We have to get rid of all the global variables in node.
Compiled extensions need know which isolate they're targeting, and we need
to decide if we want to load the extension multiple times or just once.
Also, some changes to libuv are necessary, since we will have to completely
clean up a loop. Finally we'll have to deal with debugging a multi-threaded
node process. (Ben, Ryan)
https://github.com/joyent/node/issues/2133
- Domains. Domains provide a lightweight isolation mechanism for all i/o
related to a particular network connection (e.g. an incoming http request).
If an unhandled error is encountered, all i/o local to that particular
domain is canceled and all handles are cleaned up. An experimental
implementation can be found at https://github.com/joyent/node/commits/domains.
Some of the early work for domains will be used in Isolate support (e.g.
cleaning up handles when an Isolate is killed) (Bert, Ryan)
https://github.com/joyent/node/issues/2134
- Better allocator. Currently node uses a memory pool allocator to provide
read buffers for incoming data streams. This allocator is only
reasonably efficient for network connections and local pipes on Unix, and on
Windows when zero reads are used. For file i/o and buffered reads on Windows
we need a better story. (Igor)
https://github.com/joyent/node/issues/2135
- Addons. We need to define an easy and suggested way of building
extensions, which should be similar across all supported platforms. (Everyone)
https://github.com/joyent/node/issues/2136
> - Isolates. Node will allow users to spawn "child processes" that actually
> run in a thread. We have to get rid of all the global variables in node.
> Compiled extensions need know which isolate they're targeting, and we need
> to decide if we want to load the extension multiple times or just once.
> Also, some changes to libuv are necessary, since we will have to completely
> clean up a loop. Finally we'll have to deal with debugging a multi-threaded
> node process. (Ben, Ryan)
> https://github.com/joyent/node/issues/2133
I'm wondering what the plan is intended use is for isolates.
If I remember correctly, the main reason we want to use them to get away from using multiple system processes as we do now for processing concurrency, mainly because Windows really wants you to use threads.
If that is the case, will the current cluster APIs, and most node APIs in general, remain unchanged and as "dumb" or "smart" about clustering as they are today? For example: using cluster today you will have an http module per process with a separate pool global to that process. When I see notes like "remove all global variables" I wonder if there is a plan to change this behavior.
stream.write has no callback. Just saying.
jmar: do you mean "if a CB is not specified, return a promise instead" kind of approach?
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
It's not off the roadmap but it's not a "must have" for 0.8. This is
something Isaac will be looking at after NPM is fully functioning on
Windows. Bring your API proposals to him.
I think what Ryan meant was that "promisey" objects were going to go back in to core and that we may want to standardize them a bit more.We have several domain specific objects, which are streams, which also resolve several states at some time in the future. Files, sockets, and http among them. While the stream interface is specified there are several other states in the objects that is not specified nor is the interface entirely implemented for people to extend.
Also, in the future there are optimizations we can make if we are all in the same process.
For instance, WebWorkers are shared nothing as well but Chrome has done some recent work to allow you to pass messages to them by reference rather than suffering serialization.
-Mikeal
There is no memory sharing between isolates.
We're giving people the option of starting a new Node either as a
standalone process or as a new thread/isolate. Most people will want
to continue using processes as their method of parallelizing because
it's most robust. However some people will want to use threads because
with an addon they can do fancy synchronization between the isolates.
The isolates feature is to enable advanced parallelizing techniques in
Node addons.
I agree, but that could change if the core had a specific struct to
handle those 2 kinds of "bad" usage (something similar to Buffer) or
perhaps a C module..
---
Diogo R.
Aha. Got it. Good idea.
Synchronization like... sharing data via a Buffer?
On Nov 16, 1:36 pm, Ryan Dahl <r...@tinyclouds.org> wrote:
> We're just starting development on the new branch of Node. New
> development continues in the master branch - bug fixes go into the
> v0.6 branch. The current target for a v0.8 release is early January.
> We will continue weekly v0.6 releases throughout v0.8 development.
>
> Node v0.8 roadmap
> -----------------
>
> - Move the remaining platform functions from src/platform-*.cc into
> libuv. (Everyone)
> https://github.com/joyent/node/issues/2132
>
> - Get rid of WAF. All platforms will build using GYP. (Ben, Ryan)
> https://github.com/joyent/node/issues?labels=gyp&sort=created&directi...
>
> - Isolates. Node will allow users to spawn "child processes" that actually
> run in a thread. We have to get rid of all the global variables in node.
> Compiled extensions need know which isolate they're targeting, and we need
> to decide if we want to load the extension multiple times or just once.
> Also, some changes to libuv are necessary, since we will have to completely
> clean up a loop. Finally we'll have to deal with debugging a multi-threaded
> node process. (Ben, Ryan)
> https://github.com/joyent/node/issues/2133
>
> - Domains. Domains provide a lightweight isolation mechanism for all i/o
> related to a particular network connection (e.g. an incoming http request).
> If an unhandled error is encountered, all i/o local to that particular
> domain is canceled and all handles are cleaned up. An experimental
> implementation can be found athttps://github.com/joyent/node/commits/domains.
> Some of the early work for domains will be used in Isolate support (e.g.
> cleaning up handles when an Isolate is killed) (Bert, Ryan)
> https://github.com/joyent/node/issues/2134
>
> - Better allocator. Currently node uses a memory pool allocator to provide
> read buffers for incoming data streams. This allocator is only
> reasonably efficient for network connections and local pipes on Unix, and on
> Windows when zero reads are used. For file i/o and buffered reads on Windows
> we need a better story. (Igor)
> https://github.com/joyent/node/issues/2135
>
> - Addons. We need to define an easy and suggested way of building
> extensions, which should be similar across all supported platforms. (Everyone)
> https://github.com/joyent/node/issues/2136
If one isolate fails we will continue execution. We need the ability
to clean up and open handles and I/O requests. The current plan is
this (subject to change): each isolate has many domains, each domains
has many handles. When an isolate goes down it kills all of its
domains, which in turn kills all of its handles.
The intent with domains is simply to give the user more insight and
better control over the I/O they are preforming by grouping related
handles together. For example, if timers are set up during the process
of handling an HTTP request and the HTTP connection is terminated
because a peer hit the stop button on their browser, it would be nice
to be able to automatically cancel those timers.
This is a great explanation. +1
What constitutes failure of an isolate? Uncaught exceptions, and...?
What constitutes failure of an isolate? Uncaught exceptions, and...?
There is a certain level of resemblance between isolates and
processes, I wonder to what extent the behavioral model of am isolate
and a process will be reconciled in node? Specifically, when I write a
node app, do I need to be explicit if it is to run in a process or an
isolate, or will node runtime provide an environment that abstract
away the differences?
Besides IO and open handles, is there anything else that gets clean up
when an isolate goes away? For instance, what happens with other
isolates or processes spawned by that isolate?
There is a certain level of resemblance between isolates and
processes, I wonder to what extent the behavioral model of am isolate
and a process will be reconciled in node? Specifically, when I write a
node app, do I need to be explicit if it is to run in a process or an
isolate, or will node runtime provide an environment that abstract
away the differences?
Hi,Besides IO and open handles, is there anything else that gets clean up
when an isolate goes away? For instance, what happens with other
isolates or processes spawned by that isolate?
There is a certain level of resemblance between isolates and
processes, I wonder to what extent the behavioral model of am isolate
and a process will be reconciled in node? Specifically, when I write a
node app, do I need to be explicit if it is to run in a process or an
isolate, or will node runtime provide an environment that abstract
away the differences?I can't speak for the core team, and I suppose some of the details are still under discussion. But for my application I interpreted the need to be:
- behave identically to processes wherever possible;- be explicit about the differences in behaviour when you can't.So, if an isolate spawns a child process, the child continues to run when the isolate exits. Similarly, if an isolate forks another isolate, the child will continue to run once if the parent exits.
For most applications, there will be no difference seen by the application code between the isolate and process case.Those things that are process-wide - such as process.setuid() - cannot be faithfully emulated in isolates, so the action would apply to all isolates.
env and cwd are process-wide but you could make some kind of effort to fake these as being independent between multiple isolates in a process. In the case of cwd, I've made no effort to do that - a call to chdir() will take effect for all isolates in a process - but for my use-case this was irrelevant. In the case of env I have the usual process-wide env, and local isolate overrides that are initialised by the env passed in to fork(). There is a well-defined behaviour for these, but they are different in some situations from the conventional case; for example, they are not transitive (ie a child of a child doesn't inherit the local overrides). Again, that's enough for my use-case, but I don't know if that's a useful behaviour in the general case.Paddy
--
What are you implying here? I'm under the impression that regardless of whether your in an isolates environment or not, the child_process module will continue to spawn real os processes. At least, I sure hope.
The whole isolates pseudo-process worker thing is great and all, but it should get its own API. The child_process API (other than being unfortunately named) is just fine -- there's no need to remove this feature (and I don't believe the core team intends to).
I don't believe the intent of isolates is to emulate processes. It's an abstraction over processes. Maybe it'll be easier if we just called them "workers" -- and we can say there are thread-backed workers and process-backed workers -- both would have a shared API surface. Which one you choose just depends on your application's needs (thread-backed workers could enable efficient memory sharing tricks, process workers on *nix could open the door to CoW fork tricks).
Yes.
On Dec 7, 1:48 am, "George Snelling, Seattle" <georg...@gmail.com>
wrote:
> Ryan,
>
> I don't understand how the core team prioritizes outstanding bugs/issues vs
> new work. See
>
> https://github.com/joyent/node/issues?direction=desc&labels=&mileston...
Yes, there are many outstanding issues - but they vary widely in
importance. We have a good handle on how stable the code bases is and
we communicate that stability via version numbers - not via open
GitHub issues. If someone posts an issue for "Support auto detecting
OpenSSL in OpenBSD" we will not close it - but we also don't jump to
fix it. Our features for v0.8 are very minimal in from the user's
perspective and largely amount to simplifying and cleaning the code
base (isolates, domains).
Free Node.js eBook update: http://www.heronote.com/files/Node.js.htm