Message from discussion
v0.8 Roadmap
Received: by 10.216.140.219 with SMTP id e69mr758817wej.1.1340708893424;
Tue, 26 Jun 2012 04:08:13 -0700 (PDT)
X-BeenThere: nodejs@googlegroups.com
Received: by 10.180.104.161 with SMTP id gf1ls3466839wib.1.canary; Tue, 26 Jun
2012 04:07:50 -0700 (PDT)
Received: by 10.216.131.211 with SMTP id m61mr757281wei.9.1340708870514;
Tue, 26 Jun 2012 04:07:50 -0700 (PDT)
Received: by 10.216.131.211 with SMTP id m61mr757280wei.9.1340708870497;
Tue, 26 Jun 2012 04:07:50 -0700 (PDT)
Return-Path: <jo...@jorgechamorro.com>
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54])
by gmr-mx.google.com with ESMTPS id i17si684157wiw.0.2012.06.26.04.07.50
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 26 Jun 2012 04:07:50 -0700 (PDT)
Received-SPF: neutral (google.com: 74.125.82.54 is neither permitted nor denied by best guess record for domain of jo...@jorgechamorro.com) client-ip=74.125.82.54;
Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 74.125.82.54 is neither permitted nor denied by best guess record for domain of jo...@jorgechamorro.com) smtp.mail=jo...@jorgechamorro.com
Received: by mail-wg0-f54.google.com with SMTP id fg15so4203274wgb.23
for <nodejs@googlegroups.com>; Tue, 26 Jun 2012 04:07:50 -0700 (PDT)
d=google.com; s=20120113;
h=content-type:mime-version:subject:from:in-reply-to:date
:content-transfer-encoding:message-id:references:to:x-mailer
:x-gm-message-state;
bh=p7bAiF/4YVBn07AdQ2byLj51bzAUDA5d4p1+Y5+35HQ=;
b=HYEfKHoS2II1za5jB+eaiXID+3ueMsTHgE24NLUD9+rFWBWELbZzE8ek47KAMbowYo
CItCfAaaBVFkvMEqi0Oc4ixIa8sDHTXwyqcHnuITcEpHEin4mYHi++XeGs2mhDCNj0xx
C5jAk6jXy9Pnqcp6oLUYPElb4dteQMZoDj+NCYMjrLPmHNR1ly6Y4RH58P0bpjhq4Kj4
WK39lIhj5Cl0IsiqUVbc2yz+6ki29fLw9mSawTCwM1XoAxdJMED6YSXz4+Msrew2zOdP
NZgN6aOEISkRiWwRWSP9a/Bo44U6jCPAPo1abO4/34ZbelVnaj1cFp6ET/9MzQrA3gUx
47oQ==
Received: by 10.180.86.194 with SMTP id r2mr31824448wiz.15.1340708870059;
Tue, 26 Jun 2012 04:07:50 -0700 (PDT)
Return-Path: <jo...@jorgechamorro.com>
Received: from [192.168.1.23] (17.Red-83-36-250.dynamicIP.rima-tde.net. [83.36.250.17])
by mx.google.com with ESMTPS id q6sm4286961wiy.0.2012.06.26.04.07.48
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 26 Jun 2012 04:07:49 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: [nodejs] Re: v0.8 Roadmap
From: Jorge <jo...@jorgechamorro.com>
In-Reply-To: <6e71605e-febd-4d78-8a38-11b15a723997@googlegroups.com>
Date: Tue, 26 Jun 2012 13:07:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC884E30-DD0D-4CF4-AE06-FCBA29E1F...@jorgechamorro.com>
References: <CA+fPNJW=Su55G9M9+-DZzVbefPqHfJhkH2_P0VxQi3Wwf5a...@mail.gmail.com> <6e71605e-febd-4d78-8a38-11b15a723997@googlegroups.com>
To: nodejs@googlegroups.com
X-Mailer: Apple Mail (2.1084)
X-Gm-Message-State: ALoCoQlxAwZDBrqm+ihT5KqMKLJ7bQoX2CzStYvYPQPEm8QQ1uDB0tHvLXPeeTIX5wUIBVLeanvn
On 26/06/2012, at 02:43, GuoQing Deng wrote:
> Free Node.js eBook update: http://www.heronote.com/files/Node.js.htm=20=
> "Furthermore, users of Node are free from worries of dead-locking the =
process=97there are no locks."
Neither in a bunch of httpd processes.
> "But what about multiple-processor concurrency? Aren't threads =
necessary to scale programs to multi-core computers?"
-YES: Threads are necessary to scale programs to multi-core computers.
> "Processes are necessary to scale to multi-core computers"
-Processes *are* threads.
> "not memory-sharing threads."
-Processes *are* threads running in isolated memory spaces, and it's so =
for security reasons *not* for performance reasons.
-The ability to share memory is always a plus.
-The threads in a process share what they want to share and if they want =
to. They can also share nothing as processes do.
> "The fundamentals of scalable systems are fast networking and =
non-blocking design=97"
-But node uses multiple threads itself both to *parallelize* IO and to =
avoid blocking on IO. But it doesn't expose any threads API to its =
users.
> "the rest is message passing."
-There's no fastest way to pass a message than via a pointer and you =
can't do that across processes but you can do it across threads.
> "In future versions, Node will be able to fork new processes (using =
the Web Workers API ) which fits well into the current design."
-In other words, to exploit multiple cores node will do just what =
everybody else has been doing until now, say, httpd: fork itself.
threads_a_gogo(*) gives node users the power to parallelize the =
execution of their javascript code within a single node process. Node =
couldn't benefit before threads_a_gogo of multi-core cpus simply because =
it was lacking a threads API. But threads_a_gogo gives you one:
(*) <https://github.com/xk/node-threads-a-gogo/>
--=20
Jorge.=