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
Before this commit, libuv would abort() if waitpid() failed with EINTR.
It's unlikely that anyone actually hit this error condition: the major
UNIX platforms - with the possible exception of Solaris - don't return
EINTR when the WNOHANG flag is specified, as libuv does.
However, POSIX allows for an implementation to do whatever here: unless
explicitly forbidden, it's allowed and POSIX doesn't restrict
implementers in this particular area.
Let's opt for robustness and handle EINTR.
Before this commit, uv_fs_chown() and uv_fs_fchown() took the uid and
gid as signed integers which is wrong because uid_t and gid_t are
unsigned on most all platforms and IDs that don't fit in a signed
integer do exist.
This is not an ABI change because the size of the uid and gid arguments
do not change, only their sign.
On Windows, uv_uid_t and uv_gid_t are typedef'd as unsigned char for
reasons that are unclear. It doesn't matter: they get cast to ints when
used as function arguments. The arguments themselves are unused.
Partial fix for joyent/node#5890.
Check that a timer that is started from a check handle gets picked up
correctly, i.e. that it influences the timeout used in the next tick
of the event loop.
gcc 4.2.1 as shipped with Xcode complains incessantly about aliasing
warnings, which, while technically true, disregards the fact that the
aliased types have the same layout in memory. Squelch the warnings.
This fixes an issue where uv_spawn would not try to run a reparse point,
and continue to scan the PATH instead. Effectively, it was impossible to
spawn a symlinked binary. This commit fixes that.
Also see #748
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.
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).
