Don't keep writing until the write queue fills up. On fast systems (mine), that
never happens - the data is sent out as fast as the benchmark generates it.
* Use link_settings instead of direct_dependent_settings.
* Fix typo: s/ldlags/ldflags/
Pointed out by a certain R.L. Dahl of San Francisco, CA.
Fixes#618.
You can now select to build a shared object at configure time:
$ ./gyp_uv -Dcomponent=shared_library -Dlibrary=shared_library
And build it with:
$ make -C out BUILDTYPE=Debug # or BUILDTYPE=Release
Or, if you use ninja:
$ ninja -C out/Debug
This patch creates a new header - ev-proto.h - which contains all of the
protoypes for libev functions. This allows us to create a shared object of
libuv without exposing libev internal functions.
This reverts commit 5da380a5ca.
Contains a bug that effectively makes the select() thread busy-loop. The file
descriptor is polled for both reading and writing, regardless of what events
the main thread wants to receive. Fixing that requires proper synchronization
between the two threads.
See #614.
This reverts commit 31f9fbce63.
The reverted commit depends on commit 5da380a ("use select() for specific fds
on OS X") which polls /dev/tty file descriptors in a separate thread to work
around deficiencies in the kqueue API on OS X.
Unfortunately, 5da380a has a bug that effectively makes the select() thread
busy-loop. Revert this commit for now.
Export compile-time defines that influence the size of struct stat.
This should avoid sizeof(struct stat) mismatches between libuv and dependent
projects.
On OS X, _DARWIN_USE_64_BIT_INODE=1 is also exported.
Currently, `uv_spawn` will set `environ` to the value of `options.env`, even if
`options.env` is `NULL`. This results in child processes for whom `environ ==
NULL`, which can cause a variety of unexpected issues.
This is a back-port of commit 1d85815 from the master branch.
Currently, `uv_spawn` will set `environ` to the value of `options.env`, even if
`options.env` is `NULL`. This results in child processes for whom `environ ==
NULL`, which can cause a variety of unexpected issues.
UV_EPIPE is not an error per se, it simply indicates that the other end of the
connection - i.e. the test case - has gone away.
Pro-actively ignore UV_ECANCELED errors. They're not actually emitted right now
because there's only ever one pending write but let's be forward compatible.
Relocate the include of TargetConditionals.h and fixe the use of
TARGET_OS_IPHONE. Furthermore, uv__fsevents_init() and uv__fsevents_close are
now empty functions for iOS, since the FSEvents API is not available there.
Guard against the possibility that the queue is emptied while we're iterating
over it. Simple test case:
#include "ngx-queue.h"
#include <assert.h>
int main(void) {
ngx_queue_t h;
ngx_queue_t v[2];
ngx_queue_t* q;
unsigned n = 0;
ngx_queue_init(&h);
ngx_queue_insert_tail(&h, v + 0);
ngx_queue_insert_tail(&h, v + 1);
ngx_queue_foreach(q, &h) {
ngx_queue_remove(v + 0);
ngx_queue_remove(v + 1);
n++;
}
assert(n == 1); // *not* 2
return 0;
}
Fixes#605.
Reopen the file descriptor when it refers to a tty. This lets us put the tty in
non-blocking mode without affecting other processes that share it with us.
Fixes#601.
This reverts commit 209abbab27.
Fixes the following SIGSEGV:
(gdb) f 1
#1 0x00007fc084683aec in uv__async_io (loop=0x7fc0848e0b40,
handle=0x7fc0848e0c78, events=1) at src/unix/async.c:175
175 ASYNC_CB(h)
(gdb) list
170
171 /* If we need to sweep all handles anyway - skip this loop */
172 if (!loop->async_sweep_needed) {
173 for (i = 0; i < end; i += sizeof(h)) {
174 h = *((uv_async_t**) (buf + i));
175 ASYNC_CB(h)
176 }
177 }
178
179 bytes -= end;
(gdb) print *h
$1 = {close_cb = 0x184e1b0, data = 0x18d9520, loop = 0x7fc0848e0b40,
type = 49, handle_queue = {prev = 0x18dae10, next = 0x7860c0}, flags = 32,
next_closing = 0x1863b40, pending = 0, async_cb = 0x31,
queue = {prev = 0x18dae50, next = 0x7860c0}}
(gdb)
It looks like the async handle gets closed or otherwise becomes invalid before
the sweep is executed.
Fixes#603.
