This patch adds the `uv_stream_set_blocking` API which makes all
uv_write calls to that stream blocking. It currently only works for
pipes, on windows.
Work around the build name issues by instead manually adding the build
target for android builds using '-DOS=android'
This additionally resolves problems caused by the OS variable being
rewritten from "android" to "linux" in gyp. This causes errors, as
real-time support (-lrt) and pthread support (-lpthread) is not
available in the android NDK toolchain as libraries.
The functions present in these libraries are included automatically
during the build instead during the android compilation process.
QUEUE_DATA used to cast a pointer to long and back to pointer. This can
corrupt pointers on systems where the long type isn't large enough to
store pointer, like Windows x64. This commit fixes that.
Fixes#835
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.
Tested most of my compilation in the previous patch on NodeJS
and extracted the patches from there. This patch ensures libuv
will be capable of building standalone as well, both with gyp
and Makefiles.
Build documentation was added to the README.md file.
Some tests are failing, and I have not heavily investigated
the reasons. The failures are generally on errors, and are
likely related to differences between fully POSIX-compatible
systems and android.
They're BSD-isms and obsolete ones at that. Replace with S_IRUSR and
S_IWUSR. Alias as _S_IREAD and _S_IWRITE on Windows because the '90s
never ended in Redmond, WA.
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.
Changes since version 0.11.3:
* windows: make uv_spawn not fail when the libuv embedding application
is run under external job control (Bert Belder)
* darwin: assume CFRunLoopStop() isn't thread-safe, fixing a race
condition when stopping the 'stdin select hack' thread (Fedor Indutny)
* win: fix UV_EALREADY not being reported correctly to the libuv user in
some cases (Bert Belder)
* darwin: make the uv__cf_loop_runner and uv__cf_loop_cb functions
static (Ben Noordhuis)
* darwin: task_info() cannot fail (Ben Noordhuis)
* unix: add error mapping for ENETDOWN (Ben Noordhuis)
* unix: implicitly signal write errors to the libuv user (Ben Noordhuis)
* unix: fix assertion error on signal pipe overflow (Bert Belder)
* unix: turn off POLLOUT after stream connect (Ben Noordhuis)
* unix: fix stream refcounting buglet (Ben Noordhuis)
* unix: remove assert statements that are no longer correct (Ben
Noordhuis)
* unix: appease warning about non-standard `inline` (Sean Silva)
* unix: add uv__is_closing() macro (Ben Noordhuis)
* unix: stop stream POLLOUT watcher on write error (Ben Noordhuis)
* include: document uv_update_time() and uv_now() (Ben Noordhuis)
* linux: fix cpu model parsing on newer arm kernels (Ben Noordhuis)
* linux: fix a memory leak in uv_cpu_info() error path (Ben Noordhuis)
* linux: don't ignore out-of-memory errors in uv_cpu_info() (Ben
Noordhuis)
* unix, windows: move uv_now() to uv-common.c (Ben Noordhuis)
* test: fix a compilation problem in test-osx-select.c that was caused
by the use of c-style comments (Bert Belder)
* darwin: use uv_fs_sendfile() use the sendfile api correctly (Wynn
Wilkes)
* windows: call idle handles on every loop iteration, something the unix
implementation already did (Bert Belder)
* test: update the idle-starvation test to verify that idle handles are
called in every loop iteration (Bert Belder)
* unix, windows: ensure that uv_run() in RUN_ONCE mode calls timers that
expire after blocking (Ben Noordhuis)
Before this commit, creating an event loop, starting a timer and
calling uv_run(UV_RUN_ONCE) blocked in uv_run() until the timer
expired - but didn't actually run the timer.
This mimicks what the unix implementation does: call idle handles on
every loop iteration. The guarantee that it runs on every loop iteration
makes it easier to predict and opens up more use cases.
Note that the name uv_idle is now a bit of a misnomer. There is
actually no guarantee that libuv completely processed all i/o
when an iteration ends. The windows implementation at least limits
the amount of callbacks processed in a single iteration to avoid some
handles getting a disproportionate amount of cpu attention.
Clang warns about using `inline`, which is not technically allowed in
C89 mode (libuv compiles with `-std=c89`). It's probably best to leave
it to the compiler to do the inlining anyway.
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.
