arm64 doesn't have a epoll_wait() system call but a logic error stopped
libuv from falling back to epoll_pwait().
This bug was introduced in commit libuv/libuv@67bb2b5 ("linux: fix
epoll_pwait() regression with < 2.6.19") which sadly exchanged one
regression for another.
This commit is a back-port of libuv/libuv@1d8332f and should help
get the ARMv8 buildbot in better shape.
Original-PR-URL: https://github.com/libuv/libuv/pull/308
PR-URL: https://github.com/iojs/io.js/pull/1365
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Revert uv_thread_self() to return unsigned long instead of uv_thread_t.
This was causing a build failure on Windows and is only a temporary fix
until the proper patch lands upstream.
Reverts: https://github.com/joyent/libuv/commit/59658a8
Fixes: ce112c2 "deps: update uv to v1.0.0-rc2"
Profiling suggested that on Linux sometimes over 10% of CPU time was
being spent inside the systemtap probe entry points in the binding
layer, even when the process was not actively being traced with the
`stap` tool.
That's why this commit makes it possible to use the *_ENABLED() macros
and bail out early when we're not being traced, reducing the overhead
of unused probes to (almost) zero.
Said macros were already being generated by `dtrace -h` but were not
usable because they rely on external definitions. To remedy that, we
now generate the accompanying object files with `dtrace -G`.
This commit includes a change to libuv that has been landed upstream in
commit joyent/libuv@3c172ea.
This commit changes src/tcp_wrap.cc and src/udp_wrap.cc just enough to
get by (i.e. to compile and function correctly.)
The new libuv API allows for more cleanup and deduplication but I'm
saving that for another day.