When a pipe server is closed, all pending accept requests and their
associated HANDLEs are closed to force windows to cancel the
ConnectNamedPipe IRP. The returned request has the `pipeHandle` field
set to INVALID_HANDLE_VALUE, which trips an assert in
uv_pipe_process_accept_req. This patch fixes that.
Some scandir implementations allocate the dirent struct even if the
directory is empty, so if `scandir` returns 0 there may still be memory
that needs to get deallocated. I have altered uv__fs_readdir to go to
the "deallocation exit area" when 0 files are found in the directory
and continue to return early on a return value of -1.
I went to add a test for this functionality, but it appears that one
already exists (reading an empty directory), so I imagine that the
valgrind builds must only be happening on linux instead of OSX as well?
I have confirmed manually that a program without this fix will
infinitely leak memory, and with this fix the memory usage stays
constant.
Commit 3d2c820 back-ports a patch from the master branch that disables
the use of SO_REUSEPORT on Linux for reasons mentioned in the commit
log.
Unfortunately, the back-port was incomplete; another setsockopt() call
site in src/unix/udp.c was overlooked. This commit rectifies that.
Hat tip to Luca Bruno for helping troubleshoot the issue.
When fd is closed and new one (with the same number) is opened inside
kqueue/epoll/port loop's callback - stale events might invoke callbacks
on wrong watchers.
Check if watcher was changed after invocation and invalidate all events
with the same fd.
fix#826
Work around an epoll quirk where it sometimes reports just the EPOLLERR
or EPOLLHUP event. In order to force the event loop to move forward,
we merge in the read/write events that the watcher is interested in;
uv__read() and uv__write() will then deal with the error or hangup in
the usual fashion.
Fixes#982.
This is a back-port of commit 24bfef2 from the master branch.
Gyp will try a parallel build if it detect the system has >1 processor.
This functionality depends on the Python "multiprocessing" package. The
multiprocessing package on Windows requires that the top-level module is
importable as a module, see:
http://docs.python.org/2/library/multiprocessing.html#windows
This fixes issue #984.
This is a back-port of commit 2445467 from the master branch.
On the BSDs, SO_REUSEPORT is pretty much SO_REUSEADDR with some special
casing for IP multicast. When two processes (that don't do multicast)
bind to the same address, only the last one receives traffic. It allows
one to "steal" the bound address from another process. (Both processes
have to enable SO_REUSEPORT though, so it only works in a cooperative
setting.)
On Linux however, it enables port sharing, not stealing - both processes
receive a share of the traffic. This is a desirable trait but pre-3.9
kernels don't support the socket option and a libuv program therefore
behaves differently with older kernels or on another platform.
This is a back-port of commit 9d60f1e from the master branch.
Fixesjoyent/node#6454.
Watchers could be stopped between two `kevent()`/`epoll_wait()` calls
(which may happen in the same loop in `uv__io_poll()`), in such cases
`watcher->events` could be stale and won't be updated to
`watcher->pevents`.
Try to use and rely on `watcher->pevents` instead of blindly expecting
`watcher->events` to be always correct.
This commit reverts the following commits:
983fa68 darwin: fix 10.6 build error in fsevents.c
684e212 fsevents: use shared FSEventStream
ea4cb77 fsevents: FSEvents is most likely not thread-safe
9bae606 darwin: create fsevents thread on demand
Several people have reported stability issues on OS X 10.8 and bus
errors on the 10.9 developer preview.
See also joyent/node#6296 and joyent/node#6251.
The cleanup-after-error code path in uv_spawn() was closing file
descriptors indiscriminately. Only close file descriptors that we
created ourselves, not the ones that are passed in by the user.
Fixesjoyent/node#6297.
It turns out that node.js relies on the blocking behavior of pipes in
some cases, notably when forking worker processes. Reopens#941.
This reverts commit 8fe4ca686b.
Don't rely on the caller to set the O_NONBLOCK flag on the file
descriptor.
Prevents sporadic stalls when the file descriptor is in blocking mode
and exactly as many bytes are read as there are available; in that case,
libuv will try to read again and block. Node.js was guilty of this.
Fixes#941.
Work around an 'initializer element is not constant' build error in
src/unix/fsevents.c by turning the const int flags into #defines.
Only an issue on OS X 10.6 due to the old compiler it uses.
Fixes#908.
This is a back-port of commit 82f2472 from the master branch.
Until now we assumed that _open_osfhandle() would set _doserrno on
failure. This assumption was very wrong in one obvious case, namely when
the CRT file descriptor table would fill up. In that case errno is set
to EMFILE, but GetLastError() returns zero - which makes sense because
it's not a win32 error but rather a CRT problem.
Before, when the user passed an invalid paramter to uv_fs_open, libuv
would detect this and call SET_REQ_RESULT to set the result value to -1.
SET_REQ_RESULT then stored whatever error code was returned by
GetLastError(), which would have no relationship to the actual problem,
and might as well be zero.
A couple of issues prevented uv_shutdown() from working correctly with
write-only pipes.
* The pipe handle wasn't opened with the right permissions, so an
attempt to probe the state of the write buffer would fail with
ERROR_ACCESS_DENIED.
* The pipe flags for child process stdio pipes were always set to
UV_HANDLE_READABLE and UV_HANDLE_WRITABLE, even in cases where it
was actually half-duplex.
* There was no code path that lead to closing the pipe handle if the
pipe was write-only.
Before this patch libuv would attempt to use GetLastError() to retrieve
the cause of NtQueryInformationFile failure, but that's not how it
should be done.
Changes since version 0.10.14:
* fsevents: create FSEvents thread on demand (Ben Noordhuis)
* fsevents: use a single thread for interacting with FSEvents, because
it's not thread-safe. (Fedor Indutny)
* fsevents: share FSEventStream between multiple FS watchers, which
removes a limit on the maximum number of file watchers that can be
created on OS X. (Fedor Indutny)
It seems that number of simultaneously opened FSEventStreams is
limited on OSX (i.e. you can have only fixed number of them on
one running system), getting past through this limit will cause
`FSEventStreamCreate` to return false and write following message
to stderr:
(CarbonCore.framework) FSEventStreamStart: register_with_server:
ERROR: f2d_register_rpc() => (null) (-21)
To prevent this, we must use only one shared FSEventStream with a
paths for all uv_fsevent_t handles, and then filter out events for
each handle using this paths again.
See https://github.com/joyent/node/issues/5463
Conflicts:
include/uv-private/uv-darwin.h
src/unix/fsevents.c
* Move CF run loop code to fsevents.c.
* Create the fsevents thread on demand rather than at startup.
* Remove use of ACCESS_ONCE. All accesses to loop->cf_loop are
protected by full memory barriers so no reordering can take place.
Fixes#872.
Conflicts:
src/unix/darwin.c
