Version 0.9.3 (Unstable)

167 views
Skip to first unread message

Isaac Schlueter

unread,
Oct 24, 2012, 1:11:23 PM10/24/12
to nodejs
2012.10.24, Version 0.9.3 (Unstable)

* V8: Upgrade to 3.13.7.4

* crypto: Default to buffers instead of binary strings (isaacs, Fedor Indutny)

* crypto: add getHashes() and getCiphers() (Ben Noordhuis)

* unix: add custom thread pool, remove libeio (Ben Noordhuis)

* util: make `inspect()` accept an "options" argument (Nathan Rajlich)

* https: fix renegotation attack protection (Ben Noordhuis)

* cluster: make 'listening' handler see actual port (Aaditya Bhatia)

* windows: use USERPROFILE to get the user's home dir (Bert Belder)

* path: add platform specific path delimiter (Paul Serby)

* http: add response.headersSent property (Pavel Lang)

* child_process: make .fork()'d child auto-exit (Ben Noordhuis)

* events: add 'removeListener' event (Ben Noordhuis)

* string_decoder: Add 'end' method, do base64 properly (isaacs)

* buffer: include encoding value in exception when invalid (Ricky Ng-Adam)

* http: make http.ServerResponse no longer emit 'end' (isaacs)

* streams: fix pipe is destructed by 'end' from destination (koichik)



Macintosh Installer (Universal): http://nodejs.org/dist/v0.9.3/node-v0.9.3.pkg








Other release files: http://nodejs.org/dist/v0.9.3/



Shasums:

```
188b3ffacdc4342dc3c34e7ea8374acc3e186df0  node-v0.9.3-darwin-x64.tar.gz
94ae90f06a5bf72bb6efa8053c0beefde21f8bd7  node-v0.9.3-darwin-x86.tar.gz
ccb065fe242f15ffe35ecd7b22db33d11d6a5951  node-v0.9.3-linux-x64.tar.gz
0febfb1c37a3560b0140f7f952042aa4b4712974  node-v0.9.3-linux-x86.tar.gz
4362fdfefa0ed2985045883cea51ab802555c24c  node-v0.9.3-sunos-x64.tar.gz
f43b6ce2a5da3bb384f6c115826cd2fea5f4bc2c  node-v0.9.3-sunos-x86.tar.gz
ff6a7f8ff1a6d1af299a2702e09eec2cdfef474a  node-v0.9.3-x86.msi
d47f953ee97047e1202350db2b11fb880ce2809b  node-v0.9.3.pkg
34b7406e1da49bf0f0967e5a084157fdf8735078  node-v0.9.3.tar.gz
d0829f57b8460807cf58b2154b16176ef68189b1  node.exe
76007380d1f5cefd772b5890cd64f409ba85893e  node.exp
fbe95014f9f4e2c5a38bc67b75511683f4a17fa9  node.lib
8c405af98ce922bf9bd82d29723aa343f3ca5488  node.pdb
04c1dce1188f4c52adfda0bc8219c478ed6553a8  x64/node-v0.9.3-x64.msi
fe6af3bd1405ecdef826a31a7c1333819aab4f3b  x64/node.exe
abc9afb5ac40276346072f85601bd1a9e5135856  x64/node.exp
41622dce275f0f0f740485cca8d86ba3e63c884e  x64/node.lib
8c34040ba4aa916d13c8313514cf93f99f5e3e34  x64/node.pdb
```

darcy

unread,
Oct 24, 2012, 11:44:58 PM10/24/12
to nod...@googlegroups.com, i...@izs.me
unix: add custom thread pool, remove libeio 

Is it for performance improvements? Is there any benchmark?

Ben Noordhuis

unread,
Oct 24, 2012, 11:50:13 PM10/24/12
to nod...@googlegroups.com
On Thu, Oct 25, 2012 at 5:44 AM, darcy <free...@gmail.com> wrote:
> unix: add custom thread pool, remove libeio
>
> Is it for performance improvements? Is there any benchmark?

It's in-progress work but yes, the goal is to make the thread pool
more efficient and scalable. It's not there yet though. :-)

Ted Young

unread,
Oct 25, 2012, 12:07:49 AM10/25/12
to nod...@googlegroups.com
At node summercamp, https was in heavy discussion.  Has the road map become clearer since then?

Cheers,
Ted

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

James Jiang

unread,
Oct 26, 2012, 5:21:09 AM10/26/12
to nod...@googlegroups.com
Is there a performance limitation for libeio, Or the eio thread pool is no efficient today?
Could you please explain clearly? Because we have already use 'eio_custom' function in our add-on.

Thanks

Ben Noordhuis

unread,
Oct 26, 2012, 7:40:28 AM10/26/12
to nod...@googlegroups.com
On Fri, Oct 26, 2012 at 11:21 AM, James Jiang <jav...@gmail.com> wrote:
> Is there a performance limitation for libeio, Or the eio thread pool is no
> efficient today?
> Could you please explain clearly? Because we have already use 'eio_custom'
> function in our add-on.

libeio works okay but not great for our purposes (as evidenced by
node's rather abysmal performance on file I/O benchmarks). We think we
can improve on that with a custom thread pool that's tailored to our
needs. The other reason is that we want to share the thread pool
implementation between Windows and UNIX.

Re: eio_custom(), you can use uv_queue_work() instead.
Reply all
Reply to author
Forward
0 new messages