#
0c3b061a |
| 13-Jun-2013 |
Ben Noordhuis |
Merge remote-tracking branch 'origin/v0.10' Conflicts: src/unix/stream.c src/version.c
|
#
12210fe5 |
| 08-Jun-2013 |
Ben Noordhuis |
unix: fix busy loop, write if POLLERR or POLLHUP 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 tha
unix: fix busy loop, write if POLLERR or POLLHUP 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. Fixes joyent/node#5504.
show more ...
|
#
536c5f86 |
| 08-Jun-2013 |
Ben Noordhuis |
unix: clear UV_STREAM_SHUTTING after shutdown() Fix a state machine buglet where the UV_STREAM_SHUTTING flag didn't get cleared. |
#
3ab35436 |
| 07-Jun-2013 |
Ben Noordhuis |
unix: remove overzealous assert 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 rea
unix: remove overzealous assert 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.
show more ...
|
#
c16ed503 |
| 07-Jun-2013 |
Ben Noordhuis |
Merge remote-tracking branch 'origin/v0.10' Conflicts: AUTHORS ChangeLog src/unix/stream.c src/version.c
|
#
8e4b248c |
| 05-Jun-2013 |
Ben Noordhuis |
unix: unconditionally stop handle on close Make sure the handle is fully stopped by the time uv__stream_close() calls uv_read_stop(). Fixes the following assertion: Assertio
unix: unconditionally stop handle on close 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. Fixes joyent/node#5622.
show more ...
|
#
442d11d6 |
| 25-May-2013 |
Ben Noordhuis |
unix: avoid extra read, short-circuit on POLLHUP Avoid going through an extra alloc_cb -> read() -> read_cb cycle when the POLLHUP flag is set because we know the next read() will hit EO
unix: avoid extra read, short-circuit on POLLHUP Avoid going through an extra alloc_cb -> read() -> read_cb cycle when the POLLHUP flag is set because we know the next read() will hit EOF. Fixes #803.
show more ...
|
#
b329d51e |
| 26-May-2013 |
Ben Noordhuis |
unix: stop stream POLLOUT watcher on write error The node.js test suite sometimes hits the assert that was added in commit 4146805 that checks if there are connect, write or shutdown
unix: stop stream POLLOUT watcher on write error 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.
show more ...
|
#
fc6a2ad2 |
| 08-May-2013 |
Linus Mårtensson |
unix: support for android builds Adds targets and fixes to ensure building for android works. To build on android, refer to the android standalone toolchain. |
#
8ef9592a |
| 29-May-2013 |
Ben Noordhuis |
Merge remote-tracking branch 'origin/v0.10' Conflicts: ChangeLog src/unix/stream.c src/version.c
|
#
b38c9c10 |
| 25-May-2013 |
Ben Noordhuis |
unix: remove erroneous asserts 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 wri
unix: remove erroneous asserts 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.
show more ...
|
#
636a13b8 |
| 23-May-2013 |
Ben Noordhuis |
unix: fix stream refcounting buglet 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 ha
unix: fix stream refcounting buglet 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.
show more ...
|
#
fe7b1544 |
| 24-May-2013 |
Ben Noordhuis |
Revert "unix: fix stream refcounting buglet" This change is making 45 out of 527 node.js tests fail on OS X with the following assertion: Assertion failed: (!uv__is_active(h
Revert "unix: fix stream refcounting buglet" 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 80f2f826bf90b84e659321c0b7fd8af419acb85e. Conflicts: src/unix/stream.c
show more ...
|
#
41468050 |
| 23-May-2013 |
Ben Noordhuis |
unix: turn off POLLOUT after stream connect 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
unix: turn off POLLOUT after stream connect 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.
show more ...
|
#
80f2f826 |
| 23-May-2013 |
Ben Noordhuis |
unix: fix stream refcounting buglet 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 ha
unix: fix stream refcounting buglet 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.
show more ...
|
#
c53fe815 |
| 22-May-2013 |
Ben Noordhuis |
unix: implicitly signal write errors to libuv user Fix an infinite loop in the example below when the stream encounters an EPIPE/ECONNRESET/etc. error: // keep writing until
unix: implicitly signal write errors to libuv user 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. Fixes joyent/node#5516.
show more ...
|
#
5879c613 |
| 12-May-2013 |
Ben Noordhuis |
unix: remove errno preserving code Remove the errno preserving code. Libuv only implemented it in a haphazard way and there seems to be a general consensus that no one really cares a
unix: remove errno preserving code Remove the errno preserving code. Libuv only implemented it in a haphazard way and there seems to be a general consensus that no one really cares anyway. Therefore, remove it.
show more ...
|
#
7d7fe6a9 |
| 12-May-2013 |
Ben Noordhuis |
unix: clean up uv_accept() |
#
ebdeaed2 |
| 02-May-2013 |
Ben Noordhuis |
Merge remote-tracking branch 'origin/v0.10' Conflicts: ChangeLog src/version.c
|
#
b3ab332b |
| 01-May-2013 |
Ben Noordhuis |
unix: fix EMFILE error handling On Linux, the accept() and accept4() system calls checks for EMFILE before checking for EAGAIN. Refine our EMFILE error handling tactic to deal with t
unix: fix EMFILE error handling On Linux, the accept() and accept4() system calls checks for EMFILE before checking for EAGAIN. Refine our EMFILE error handling tactic to deal with that. Here is what used to happen: 1. The event loop calls accept() and sees EMFILE. 2. Libuv switches to EMFILE error handling mode. It closes a stashed file descriptor and calls accept() again. 3. The accept() system call fails with EAGAIN. 4. Libuv reopens the stashed file descriptor (reaching RLIMIT_NOFILE again) and returns control to the regular event loop. 5. The regular event loop calls accept(), sees EMFILE and jumps to step 2 again. Effectively an infinite loop. Avoid that by not calling accept() again when we've seen EAGAIN. Fixes joyent/node#5389.
show more ...
|
#
67f9b91a |
| 30-Apr-2013 |
Fedor Indutny |
stream: use harder sync restrictions for osx-hack Synchronize harder to avoid excessive spins, invokations of async callback and sporadic assertion failures on double-call of async c
stream: use harder sync restrictions for osx-hack Synchronize harder to avoid excessive spins, invokations of async callback and sporadic assertion failures on double-call of async callback.
show more ...
|
#
ac4e7e7f |
| 26-Apr-2013 |
Fedor Indutny |
stream: fix small nit in select hack, add test |
#
2400716d |
| 24-Apr-2013 |
Fedor Indutny |
stream: fix osx select hack After latest twiddling, `stream->io_watcher.fd` doesn't contain a real stream's file descriptior anymore. The one from `select_state` should be used inste
stream: fix osx select hack After latest twiddling, `stream->io_watcher.fd` doesn't contain a real stream's file descriptior anymore. The one from `select_state` should be used instead. Zero-initialize `select_state->event` field.
show more ...
|
#
8041c52f |
| 10-Apr-2013 |
Ben Noordhuis |
unix: style fixups |
#
f78bcfbd |
| 10-Apr-2013 |
Ben Noordhuis |
Merge remote-tracking branch 'origin/v0.10'
|