This handles the fact that stream.Writable inherits from the Stream class, meaning that it has the legacy pipe() method. Override that with a pipe() method that emits an error. Ensure that Duplex streams ARE still pipe()able, however. Since the 'readable' flag on streams is sometimes temporary, it's probably better not to put too much weight on that. But if something is an instanceof Writable, rather than of Readable or Duplex, then it's safe to say that reading from it is the wrong thing to do. Fix #3647
It is not a valid test unless you're connected to the internet, and causes a lot of spurious failures on Linux anyway, as it's highly dependent on timing of things that we don't have any control over.
This makes the output of simple/test-debugger-repl and simle/test-debugger-repl-utf8 mirror an actual debugger session, so it's a bit easier to reason about. Also, it uses the same code for both, and fixes it so that it doesn't leave zombie processes lying around when it crashes. Run 1000 times without any failures or zombies.
Handle break events that come out sometimes, by telling it to continue. Also, send the child a SIGTERM when it times out.
Starting the debugger directly in the SIGUSR1 signal handler results in a malloc lock contention ~1% of the time. It hangs the test, which is annoying on a daily basis to all of us, but it also is pretty terrible if you actually want to debug a node process that has gone sideways. Credit to @bnoordhuis for most of this. I just added the unref which keeps it from messing up the event loop for other stuff.
The CI system requires that some environment variables are set so merge our variables into the current environment instead of blindly replacing it. This will probably have to be repeated for other tests. C'est la vie.
Raspberry Pi is an example. BUG=v8:2393 Review URL: https://chromiumcodereview.appspot.com/11570061 Patch from Chi-Thanh Christopher Nguyen <firstname.lastname@example.org>. git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@13232 ce2b1a6d-e550-0410-aec6-3dcde31c8c00 This is a backport of v8/v8@44419ad.
See http://code.google.com/p/v8/issues/detail?id=2493 for details. This commit reapplies 9668df8. The issue has been fixed upstream but reappeared after last night's downgrade to V8 3.14.5 in commit b15a10e. Conflicts: test/simple/test-buffer.js
Regardless of previous @bnoordhuis' changes
This reverts commit f80f3c5.
Do not run the http/simple.js server in a child process. Fix #4831
Commit 3d67f89 ("fix generation of v8 constants on freebsd") is an unfortunate victim of this rollback. Revert "dtrace: fix generation of v8 constants on freebsd" Revert "dtrace: More style" Revert "dtrace: Make D style more D-ish" Revert "dtrace: x64 ustack helper" Revert "dtrace: fix style in ustack helper" Revert "dtrace: SeqAsciiString was renamed to SeqOneByteString in v8" This reverts commit 3d67f89. This reverts commit 321b8ee. This reverts commit 38df9d5. This reverts commit f9afb3f. This reverts commit 13296e4. This reverts commit 3b715ed.
Reapply floating patches. Special mention: also reapplies 017009f but with the extra change of removing DescriptorArray::kTransitionsIndex from the postmortem metadata generator because said field no longer exists in V8 3.14.
V8 3.15 and newer have stability and performance issues. Roll back to a known-good version.
Only handle objects if explicitly told to do so in the options object. Non-buffer/string chunks are an error if not already in objectMode. Close #4662
The Readable and Writable classes will nextTick certain things if in sync mode. The sync flag gets unset after a call to _read or _write. However, most of these behaviors should also be deferred until nextTick if no reads have been made (for example, the automatic '_read up to hwm' behavior on Readable.push(chunk)) Set the sync flag to true in the constructor, so that it will not trigger an immediate 'readable' event, call to _read, before the user has had a chance to set a _read method implementation.
The functionality is available again per joyent/libuv@14eb8b0 and joyent/libuv@e89aced. Fixes #3687.
Also, this adds a test that guarantees that the ordering of several push() calls in a row is always preserved in synchronous readable streams
There are cases where a push() call would return true, even though the thing being pushed was in fact way way larger than the high water mark, simply because the 'needReadable' was already set, and would not get unset until nextTick. In some cases, this could lead to an infinite loop of pushing data into the buffer, never getting to the 'readable' event which would unset the needReadable flag. Fix by splitting up the emitReadable function, so that it always sets the flag on this tick, even if it defers until nextTick to actually emit the event. Also, if we're not ending or already in the process of reading, it now calls read(0) if we're below the high water mark. Thus, the highWaterMark value is the intended amount to buffer up to, and it is smarter about hitting the target.
It seems like a good idea on the face of it, but lowWaterMarks are actually not useful, and in practice should always be set to zero. It would be worthwhile for writers if we actually did some kind of writev() type of thing, but actually this just delays calling write() and the overhead of doing a bunch of Buffer copies is not worth the slight benefit of calling write() fewer times.