Version 0.7.10 (unstable, but please read anyway)

182 views
Skip to first unread message

Isaac Schlueter

unread,
Jun 11, 2012, 11:59:52 AM6/11/12
to nodejs, NodeJS Dev
2012.06.11, Version 0.7.10 (unstable)

This is the second-to-last release on the 0.7 branch. Version 0.8.0
will be released some time next week. As other even-numbered Node
releases before it, the v0.8.x releases will maintain API and binary
compatibility.

The major changes are detailed in
https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8

Please try out this release. There will be very few changes between
this and the v0.8.x release family. This is the last chance to comment
on the API before it is locked down for stability.


* Roll V8 back to 3.9.24.31

* build: x64 target should always pass -m64 (Robert Mustacchi)

* add NODE_EXTERN to node::Start (Joel Brandt)

* repl: Warn about running npm commands (isaacs)

* slab_allocator: fix crash in dtor if V8 is dead (Ben Noordhuis)

* slab_allocator: fix leak of Persistent handles (Shigeki Ohtsu)

* windows/msi: add node.js prompt to startmenu (Jeroen Janssen)

* windows/msi: fix adding node to PATH (Jeroen Janssen)

* windows/msi: add start menu links when installing (Jeroen Janssen)

* windows: don't install x64 version into the 'program files (x86)'
folder (Matt Gollob)

* domain: Fix #3379 domain.intercept no longer passes error arg to cb
(Marc Harter)

* fs: make callbacks run in global context (Ben Noordhuis)

* fs: enable fs.realpath on windows (isaacs)

* child_process: expose UV_PROCESS_DETACHED as options.detached
(Charlie McConnell)

* child_process: new stdio API for .spawn() method (Fedor Indutny)

* child_process: spawn().ref() and spawn().unref() (Fedor Indutny)

* Upgrade npm to 1.1.25
- Enable npm link on windows
- Properly remove sh-shim on Windows
- Abstract out registry client and logger


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

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

Windows x64 Files: http://nodejs.org/dist/v0.7.10/x64/

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

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

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

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

Jimb Esser

unread,
Jun 11, 2012, 3:42:32 PM6/11/12
to nodejs
I'm trying out the new node version (previously on 0.6.*), and I'm
running into issues where processes spawned with child_process emit
their 'exit' event before their stdout/stderr 'data' events
(previously it seemed to always emit all data events before exiting),
causing all sorts of problems with our servers. Is this expected?
Always that way and we were just lucky before? Some undocumented API
change? Bug from the other child_process changes?

This is on Linux, and, unfortunately, doesn't seem to reproduce in a
trivial test case, just when spawning processes when lots of other
stuff is going on.

On Jun 11, 8:59 am, Isaac Schlueter <i...@izs.me> wrote:
> 2012.06.11, Version 0.7.10 (unstable)
>
> This is the second-to-last release on the 0.7 branch.  Version 0.8.0
> will be released some time next week.  As other even-numbered Node
> releases before it, the v0.8.x releases will maintain API and binary
> compatibility.
>
> The major changes are detailed inhttps://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8

Marco Rogers

unread,
Jun 11, 2012, 3:49:31 PM6/11/12
to nod...@googlegroups.com
See the changes to child_process here. https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8 

It seems like exit doesn't wait for the i/o pipes to close anymore. There's a new "close" event that might work better. I don't know the history of his change though so YMMV.

:Marco

Oliver Leics

unread,
Jun 11, 2012, 3:50:02 PM6/11/12
to nod...@googlegroups.com
snip/

child_process

* arguments and options arguments of child_process.fork() became an option.
* the 'exit' event is now emitted right after the child process
exits. It no longer waits for all stdio pipes to be closed.
* the 'close' event was added that has is emitted after the child
has exited and all the stdio pipes are closed.

/snip

taken from https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8

Change your listeners from exit to the close-event.
> --
> 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



--
Oliver Leics @ G+
https://plus.google.com/112912441146721682527

Charlie McConnell

unread,
Jun 11, 2012, 3:51:17 PM6/11/12
to nod...@googlegroups.com
The semantics of the events changed.  'exit' is emitted when the process exits - 'close' is now emitted when all stdio streams have closed.  Where you were previously listening for 'exit', you should now listen for 'close'.  The 'exit' event now fires when the child actually exits, which in many cases happens before all the data comes in.

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



--
Charlie McConnell
Head of Support
Nodejitsu, Inc.

Isaac Schlueter

unread,
Jun 11, 2012, 3:52:42 PM6/11/12
to nod...@googlegroups.com
The reasoning:

When sharing file descriptors with child process stdio, this became
very complicated. You could have a child process share its stdout
with the parent's stdout, for example.

What to do in this case? Never emit "exit" at all? What if the
parent needs to know when the child is done processing?

It led to some really awful complicated logic in many relatively
common use cases. We opted to make things more explicit and simple by
adding a "close" event which indicates that the stdio is closed, and
an "exit" event which indicates that the child has exited.

Jimb Esser

unread,
Jun 11, 2012, 5:00:16 PM6/11/12
to nodejs
Okay, thanks for the info, changing our code to proc.on('close') seems
to have resolved that issue, sorry I didn't notice the difference in
the docs, and the docs do not seem to include that very handy list of
changes (though it was in the email, I apparently skimmed over it as I
do all links in emails...).

Two other issues I'm running into with node 0.7.10 on Linux:

setTimeout with times > 350ms or so sometimes don't get called. A one-
line .js file: setTimeout(console.log, 1000, 'Test'); appears to never
display the message nor exit, about 1 in 5 times I run it.

fs.readFileSync('/proc/stat') (and async variants) now return an empty
buffer all the time, previously would return the same as running 'cat /
proc/stat'. Same with reading any other procfs file, no problem on
non-procfs files, AFAICT.

Jimb Esser

Isaac Schlueter

unread,
Jun 11, 2012, 5:15:04 PM6/11/12
to nod...@googlegroups.com
Aha, the /proc/stat thing is interesting. It reports a stat.size of
0, which is confusing the optimization in fs.readFile. (Note that
fs.createReadStream('/proc/stat') does the right thing.)

The setTimeout(fn, 1000) issue I can't reproduce on Linux, SmartOS, or OS X.

Isaac Schlueter

unread,
Jun 11, 2012, 7:05:04 PM6/11/12
to nod...@googlegroups.com
fs.readFile('/proc/stat', ...) fixed in master. Now any zero-byte
result from fstat() will cause it to read until it stops getting
bytes.

Jimb Esser

unread,
Jun 11, 2012, 9:24:38 PM6/11/12
to nodejs
Great! Thanks for the fix.

For the setTimeout issue, it seems to only happen on one of the 5
machines I tried on. git bisect traced it down to this commit:
30a0e58 uv: upgrade to 87dbffbd [1]
https://github.com/joyent/node/commit/30a0e58

Adding some printfs to the modified timer.c, as that seemed a likely
culprit, I tracked it down to the loop->time value fluctuating
greatly, looks like something is clearing it to near-0 periodically.
Similarly, running process.hrtime() over and over again fluctuates
between showing expected values and values near 0s. I'll send an email
to nodedev with details.
- Jimb Esser

On Jun 11, 4:05 pm, Isaac Schlueter <i...@izs.me> wrote:
> fs.readFile('/proc/stat', ...) fixed in master.  Now any zero-byte
> result from fstat() will cause it to read until it stops getting
> bytes.
>
>
>
>
>
>
>
> On Mon, Jun 11, 2012 at 2:15 PM, Isaac Schlueter <i...@izs.me> wrote:
> > Aha, the /proc/stat thing is interesting.  It reports a stat.size of
> > 0, which is confusing the optimization in fs.readFile.  (Note that
> > fs.createReadStream('/proc/stat') does the right thing.)
>
> > The setTimeout(fn, 1000) issue I can't reproduce on Linux, SmartOS, or OS X.
>

Shigeki Ohtsu

unread,
Jun 11, 2012, 9:33:18 PM6/11/12
to nod...@googlegroups.com

This issue was fixed in
https://github.com/joyent/libuv/pull/450
but libuv of node-0.7.10 was not updated yet.

You can resolve this issue by replacing deps/uv to the current libuv
master by manual or wait for the next release.

Jimb Esser

unread,
Jun 11, 2012, 10:13:08 PM6/11/12
to nodejs
Ah, yep, that 1-line fix to uv_hrtime fixes it, and the one machine
that was reproducing this was running 32-bit node. Hopefully that
gets in for the next version.

On Jun 11, 6:33 pm, Shigeki Ohtsu <oh...@iij.ad.jp> wrote:
> This issue was fixed inhttps://github.com/joyent/libuv/pull/450
> >>>>>> here.https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8

Isaac Schlueter

unread,
Jun 12, 2012, 10:59:23 AM6/12/12
to nodej...@googlegroups.com, nod...@googlegroups.com
It does not require admin rights (Junctions behave a lot more like
unix symlinks in node now.)

I'm not 100% sure offhand which versions it works in. I've only
tested it in Windows 7, but I think Junctions haven't really changed
since XP. Please try it out and report your findings ;)


On Tue, Jun 12, 2012 at 12:04 AM, Jan Kolkmeier <jankol...@gmail.com> wrote:
>> Enable npm link on windows
>
> Awesome - all windows versions, or just 7? I assume it requires admin
> rights?

Tim Dickinson

unread,
Jun 14, 2012, 1:16:18 PM6/14/12
to nod...@googlegroups.com, NodeJS Dev
How much is this going to break npm modules? Should i wait or should i upgrade? I want to upgrade but don't want to spend a week fixing broken packages.
Reply all
Reply to author
Forward
0 new messages