Node v0.7.0

[Ryan Dahl]

This is the first release in the unstable v0.7 series. Almost all
users will want to remain using the stable v0.6 releases.

2012.01.16, Version 0.7.0 (unstable)

* Upgrade V8 to 3.8.6

* Use GYP build system on unix (Ben Noordhuis)

* Experimenetal isolates support (Ben Noordhuis)

* Improvements to Cluster API (Andreas Madsen)

* Use isolates for internal debugger (Fedor Indutny)

* Bug fixes

Source Code: http://nodejs.org/dist/v0.7.0/node-v0.7.0.tar.gz

Windows Installer: http://nodejs.org/dist/v0.7.0/node-v0.7.0.msi

Macintosh Installer: http://nodejs.org/dist/v0.7.0/node-v0.7.0.pkg

Website: http://nodejs.org/docs/v0.7.0/

Documentation: http://nodejs.org/docs/v0.7.0/api/

[maga]

Is there any docs on isolates yet?

[Ben Noordhuis]

On Tue, Jan 17, 2012 at 14:03, maga <dene...@gmail.com> wrote:
> Is there any docs on isolates yet?

Not yet[1].

Isolates are (will be) API-compatible with child processes. So you
call child_process.fork({thread:true}) and it will spawn a new isolate
instead a new process.

[1] https://github.com/joyent/node/issues/2551

[Seva Adari]

Just curious: 

If isolates maintain complete separate states, and objects from one isolate are not be used in other isolates then how is an isolate different than a separate run of a process? 

[Paddy Byers]

Hi,

If isolates maintain complete separate states, and objects from one isolate are not be used in other isolates then how is an isolate different than a separate run of a process? 

The javascript state of isolates are completely separated from one another, but the creation cost of an isolate should be lower than that of a separate process; for example, some of the v8 state and the eio thread pool (on unix systems) will be shared.

Paddy

[Fedor Indutny]

And if process will die - all it's isolates will be dead too.

It's good for some use cases.

Cheers,

Fedor.

--
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

[Seva Adari]

So, isolate is sync'ed with the parent on the death, and for all other practical purposes, it is an independent process. I guess if your app forks a few processes, then you don't need to worry about taking them all down when parent exits, clean up is on the house. What use cases can you think of could be candidates for isolates?

[Mark Hahn]

>  What use cases can you think of could be candidates for isolates? 

I'm just guessing, but anywhere you care about performance when having to create and kill a lot of these?

On Tue, Jan 17, 2012 at 10:21 AM, Seva Adari <oddi...@gmail.com> wrote:

So, isolate is sync'ed with the parent on the death, and for all other practical purposes, it is an independent process. I guess if your app forks a few processes, then you don't need to worry about taking them all down when parent exits, clean up is on the house. What use cases can you think of could be candidates for isolates?

--

[Jann Horn]

2012/1/17 Seva Adari <oddi...@gmail.com>:

> What use cases can you think of
> could be candidates for isolates?

Theoretically, it should be possible to pass node buffers between them
(sharing would work, too, but meh, it'd just cause race conditions).
So, maybe for tasks with much input data, much output data and even
more computation that have to be done in a new thread?

[Dean Landolt]

There are a number of possible strategies for safely passing data back and forth between isolates efficiently. Isolates lay the groundwork for some really interesting concurrency experiments.

[David Worms]

I remember a video of Ryan Dahl mentioning a web server as an exemple
where requests would run in isolate. In this exemple, using isolate
prevent a process, understand the web server, to be kill in case of an
uncatch error while handling a request.

[Ted Young]

On Jan 17, 2012, at 12:51 PM, David Worms wrote:

> I remember a video of Ryan Dahl mentioning a web server as an exemple where requests would run in isolate. In this exemple, using isolate prevent a process, understand the web server, to be kill in case of an uncatch error while handling a request.

There was a separate Domains proposal to try to handle that situation within a single process. What's the status with that? Does it still seem feasible?

[Ben Noordhuis]

On Tue, Jan 17, 2012 at 22:16, Ted Young <t...@radicaldesigns.org> wrote:
> There was a separate Domains proposal to try to handle that situation within a single process.  What's the status with that?  Does it still seem feasible?

Yes and yes. Bert is working on domains but it's not ready yet.

[Mikeal Rogers]

Correct me if I'm wrong but this is the seperation.

domains are for encapsulating and handling errors in process. you can think of it like adding a wrapper around a set of application code to treat it, and all the IO it does and it's descendant callbacks, as a transaction.

isolates are a replacement for processes as the preferred method of scaling a node application to multiple cores.

running each "transaction" in an isolate would be too costly.

-Mikeal

[billywhizz]

quick question - do isolates allow us to set the processor affinity of
each isolate so we can "pin" an isolate to a particular cpu?

[Ben Noordhuis]

On Wed, Jan 18, 2012 at 00:17, billywhizz <apjo...@gmail.com> wrote:
> quick question - do isolates allow us to set the processor affinity of
> each isolate so we can "pin" an isolate to a particular cpu?

No.

[billywhizz]

thanks. that's a pity. would it be worth raising an issue with the v8
team to allow this?

On Jan 17, 11:26 pm, Ben Noordhuis <i...@bnoordhuis.nl> wrote:

[Dean Landolt]

Is this a "not on your life" no, or just a "no for now"?

[Ben Noordhuis]

On Wed, Jan 18, 2012 at 00:30, billywhizz <apjo...@gmail.com> wrote:
> thanks. that's a pity. would it be worth raising an issue with the v8
> team to allow this?

It's not a V8 issue, the isolate runs in a thread that is created by Node.

[Ben Noordhuis]

Probably the former. It's nearly always better to leave work load
scheduling to the OS. I say 'nearly' but I can't really think of a
scenario where that's not the case.

[billywhizz]

i can think of many scenarios where i would like to pin tasks to
certain cpu's to allow soft real time processing by ensuring no other
processes will be contending with the cpu the node.js isolate is on...

On Jan 17, 11:39 pm, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
> On Wed, Jan 18, 2012 at 00:30, Dean Landolt <d...@deanlandolt.com> wrote:
> > On Tue, Jan 17, 2012 at 6:26 PM, Ben Noordhuis <i...@bnoordhuis.nl> wrote:

[Seva Adari]

> What use cases can you think of could be candidates for isolates?

Theoretically, it should be possible to pass node buffers between them
(sharing would work, too, but meh, it'd just cause race conditions).
So, maybe for tasks with much input data, much output data and even
more computation that have to be done in a new thread?

There are a number of possible strategies for safely passing data back and forth between isolates efficiently. Isolates lay the groundwork for some really interesting concurrency experiments.

If the intent of isolate is to box it and separate it, why try to use it in a case where data sharing is required. If the use case requires data sharing is isolate really a candidate for it?

[Seva Adari]

i can think of many scenarios where i would like to pin tasks to
certain cpu's to allow soft real time processing by ensuring no other
processes will be contending with the cpu the node.js isolate is on...

Even if you have a way to schedule/assign to a particular core/cpu, is it

not the prerogative of the OS to either honor/dishonor it?

[Dobes]

You could probably make a native extension to do it, even if it isn't
built into node out of the box.

However, it does sound like a strange requirement at the application
level.

The OS should already favor having the same thread run on the same CPU
if it can, since that makes better
use of the CPU caches.

And, just because you told the OS to run that thread on that CPU with
high priority, it doesn't mean the OS
won't run other threads on that CPU while that task is not in a run
state.

[billywhizz]

if you use taskset and cgroups in linux you can do all sorts of things
like running everything under init on 1 cpu and then running specific
processes/threads on other cpu's. it can be useful in certain
scenarios, especially where you want as little context switching as
possible in your application (i.e. low latency).

you also may want to make sure that two threads run on specific cores
so that they share the same cpu cache(s). this would only be useful if
both threads were accessing the same shared memory.

if node.js is allowing threads to be spawned then it should support
setting thread affinity imho.

http://linux.die.net/man/1/taskset
http://linux.die.net/man/2/sched_setaffinity
http://littledaemons.wordpress.com/2009/01/22/cpu-affinity-and-taskset/

[Dean Landolt]

Yes. If you're not sharing any memory why not spin up another process? The overhead is minimal, and has worked just fine up to now. Sure, threads are a bit lighter so if you're spinning up a bunch it's more optimal to run your child processes as threads (and if IIUC it's much preferred on Windows). But really, why go through all this trouble for an optimization? I certainly can't speak for the core team but I suspect there's more to it than a modest optimization.

tl;dr: with isolates and a safe memory sharing model you can crush some fibonacci benchmarks :)

[Shiho]

I have a multi-player game where multiple players can join a match and
can alter the rules of the game on a fundamental way. Sometimes this
crashes. Creating a child process per match is unscalable. Would
isolates be a good use case here?

[Yucong Sun (叶雨飞)]

Well, I think you should store the state somewhere else and make your
process state-less, became a execution engine, you can even shard it
later to archive scalability.