Check that a timer that is started from a check handle gets picked up
correctly, i.e. that it influences the timeout used in the next tick
of the event loop.
gcc 4.2.1 as shipped with Xcode complains incessantly about aliasing
warnings, which, while technically true, disregards the fact that the
aliased types have the same layout in memory. Squelch the warnings.
This fixes an issue where uv_spawn would not try to run a reparse point,
and continue to scan the PATH instead. Effectively, it was impossible to
spawn a symlinked binary. This commit fixes that.
Also see #748
Changes since version 0.10.10:
* unix: unconditionally stop handle on close (Ben Noordhuis)
* freebsd: don't enable dtrace if it's not available (Brian White)
* build: make HAVE_DTRACE=0 should disable dtrace (Timothy J. Fontaine)
* unix: remove overzealous assert (Ben Noordhuis)
* unix: clear UV_STREAM_SHUTTING after shutdown() (Ben Noordhuis)
* unix: fix busy loop, write if POLLERR or POLLHUP (Ben Noordhuis)
This fixes a busy loop by working around a quirk with Linux kernels
<= 2.6.32 where an EPIPE or ECONNRESET error on a file descriptor that
is polled for EPOLLOUT but not EPOLLIN gets reported by epoll_wait() as
just EPOLLERR|EPOLLHUP, like this:
epoll_wait(5, {{EPOLLERR|EPOLLHUP, {u32=12, u64=12}}}, 1024, 433) = 1
Before this commit, libuv called uv__read() which attempts to read from
the file descriptor. With newer kernels and on other operating systems
that fails like this:
read(12, "", 65536) = -1 EPIPE (Broken pipe)
Which tells libuv there is a connection error and it should notify the
user of that. On the affected Linux kernels however, the read succeeds
with an EOF:
read(12, "", 65536) = 0
Which is subsequently passed on to the user. In most cases, the user
will close the handle and everything is fine.
Node.js however sometimes keeps the handle open in an attempt to flush
pending write requests. While libuv doesn't officially support this,
unofficially it works...
...except on those older kernels. Because the kernel keeps waking up
the event loop without setting POLLOUT and because the read calls EOF
but don't error, libuv's I/O state machine doesn't progress.
That's why this commit changes uv__stream_io() to also write pending
data. While the read() system call doesn't error, the write() system
call will.
Fixesjoyent/node#5504.
Several node.js users are hitting this assert under what appear to be
mostly benign conditions. In other words, it's unclear whether it's
catching real bugs or just has wrong expectations.
An aborting process is rather disruptive so I'm removing the assert
from the stable branch and relanding it in the master branch.
Make sure the handle is fully stopped by the time uv__stream_close()
calls uv_read_stop(). Fixes the following assertion:
Assertion failed: (!uv__io_active(&stream->io_watcher, UV__POLLOUT)
|| !ngx_queue_empty(&stream->write_completed_queue)
|| !ngx_queue_empty(&stream->write_queue)
|| stream->shutdown_req != NULL
|| stream->connect_req != NULL), function uv_read_stop,
file ../deps/uv/src/unix/stream.c, line 1329.
Fixesjoyent/node#5622.
The darwin sendfile implementation uses the &len parameter as input
and output. The code was sending 0 (not using the value of req->len)
so the behavior wasn't what the caller was expecting.
This makes sure to initialize len with req->len to ensure that the
caller can send portions of a file (not always everything to the
end of the file).
The node.js test suite sometimes hits the assert that was added in
commit 4146805 that checks if there are connect, write or shutdown
requests pending when the user calls uv_read_stop() while the stream
is primed for writing.
The libuv user (i.e. node.js) is supposed to close the stream on error.
Because uv__stream_close() calls uv_read_stop(), it's possible that the
POLLOUT watcher is still active.
As of commit c53fe81, it's legal for write_queue_size > 0 when the
write_queue itself is empty. Sounds illogical but it means there are
error-state write requests in the write_completed_queue that will touch
up the write_queue_size on the next tick of the event loop.
Remove a few stray asserts that still checked for the old situation.
Fix a buglet where uv_read_stop() would mark the handle as stopped even
when there are in-progress write requests.
This bug is unlikely to have affected anyone, the only case where it
has a user-visible effect is when:
a) the handle has been stopped for reading but not writing, and
b) it's the last active handle in the event loop's pollset
If both conditions are met, it's possible for the event loop to
terminate prematurely.
This reapplies commit 80f2f82 which was temporarily reverted in fe7b154
because it was making a lot of node.js tests fail on OS X with the
following assertion:
Assertion failed: (!uv__is_active(handle)), function
uv__finish_close, file ../../deps/uv/src/unix/core.c, line 165.
Expecting that the handle is inactive when the state is UV_CLOSING
turns out to be a bad assumption: it's possible that the handle is
executing (for example) a shutdown request when uv__finish_close()
is called. That's okay, uv__stream_destroy() takes care of that.
The issue wasn't specific to OS X, it was just more visible on that
platform. (Slow) debug builds on Linux exhibited the same behavior.
This change is making 45 out of 527 node.js tests fail on OS X with the
following assertion:
Assertion failed: (!uv__is_active(handle)), function
uv__finish_close, file ../../deps/uv/src/unix/core.c, line 165.
It's likely a manifestation of a bug elsewhere but, because there's a
new node.js release going out tonight, I'm reverting it for now.
This reverts commit 80f2f826bf.
Conflicts:
src/unix/stream.c
Clear the POLLOUT flag after we're done connecting. Not doing so isn't
really harmful but it may cause the event loop to wake up more often
than it has to.
Fix a buglet where uv_read_stop() would mark the handle as stopped even
when there are in-progress write requests.
This bug is unlikely to have affected anyone, the only case where it
has a user-visible effect is when:
a) the handle has been stopped for reading but not writing, and
b) it's the last active handle in the event loop's pollset
If both conditions are met, it's possible for the event loop to
terminate prematurely.
An incorrect assert() statement was causing libuv to crash when writing
to an internal signal pipe would result in EAGAIN/EWOULDBLOCK.
This commit doesn't solve the underlying issue that the signal pipe can
overflow.
This should fixjoyent/node#5538
Fix an infinite loop in the example below when the stream encounters
an EPIPE/ECONNRESET/etc. error:
// keep writing until we start buffering
while (stream->write_queue_size == 0) {
uv_write_t* req = make_write_req();
uv_buf_t buf = uv_buf_init("PING", 4);
uv_write(req, stream, &buf, 1, write_cb);
}
uv_write() does not return an error code on write errors, the error is
only reported to the callback.
Before this commit, uv_write() left stream->write_queue_size untouched
on error, meaning the caller had no way to find out about that error
until the next tick of the event loop - which in the example above
leads to an infinite loop because that next tick is indefinitely
postponed.
This commit works around that at the cost of some added internal
complexity.
Fixesjoyent/node#5516.
Use signaling mechanism for loop termination, because CFRunLoopStop() is
most likely not a thread-safe function and invoking it from other thread
may sometimes result in a "dead-lock".
fix#799
* Fix a potential issue introduced with 415f4d3, namely that uv_spawn
can fail when the current process is under job control. This would
happen on Windows versions that don't support nested jobs (versions
prior to Windows 8 / Server 2012).
* Change the `uv__init_global_job_handle` function signature to match
what `uv_once` expects.
* Add a bunch of comments that clarify how we're using job control,
and how we're dealing with job control that might be established by
our parent process.
