* windows: Re-implement uv_fs_stat. The st_ctime field now contains the
change time, not the creation time, like on unix systems. st_dev,
st_ino, st_blocks and st_blksize are now also filled out. (Bert
Belder)
* linux: fix setsockopt(SO_REUSEPORT) error handling (Ben Noordhuis)
* windows: report uv_process_t exit code correctly (Bert Belder)
* windows: make uv_fs_chmod() report errors correctly (Bert Belder)
* windows: make some more NT apis available for libuv's internal use
(Bert Belder)
* windows: squelch some compiler warnings (Bert Belder)
This improves the output of uv_fs_stat:
* `st_ctime` now contains the change time, not the creation time.
* `st_ino` is now filled in with an fs-specific unique number.
* `st_dev` is set to the serial number of the containing file system.
* `st_blocks` now gets set.
* `st_blksize` is no longer zero, but set to a reasonable default.
This commit adds bootstrap code, function signatures, struct definitions
etc. to make it possible for libuv to use NtQueryVolumeInformationFile.
Most of this comes from the NT DDK, which libuv mirrors so that people
don't need the DDK to compile it.
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.
Linux as of 3.9 has a SO_REUSEPORT option that is similar but not
identical to its BSD counterpart.
On the BSDs, it turns on SO_REUSEADDR _and_ makes it possible to share
the address and port across processes.
On Linux, it "merely" enables fair load distribution - port sharing
still requires that you set SO_REUSEADDR.
Fair distribution is a desirable trait but not an essential one.
We don't know in advance whether the kernel actually supports
SO_REUSEPORT so don't treat EINVAL or ENOPROTOOPT as errors.
As an aside, on the BSDs we now omit the setsockopt(SO_REUSEADDR)
system call because it's implied by SO_REUSEPORT.
Fixes#870.
Changes since version 0.11.8:
* 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)
* process: the `exit_status` parameter for a uv_process_t's exit
callback now is an int64_t, and no longer an int. (Bert Belder)
* process: make uv_spawn() return some types of errors immediately on
windows, instead of passing the error code the the exit callback. This
brings it on par with libuv's behavior on unix. (Bert Belder)
This means we no longer have to strip the high bit from the process exit
code on Windows, which is problematic because an unhandled SEH exception
can make a process exit with a status code that has the high bit set.
* It will now report some types of errors synchronously, to bring it on
par with uv-unix. Fixes#865.
* Failure to find the target executable will now set up stdio pipes
correctly, so the user can assume that when uv_spawn() returns 0 these
pipes will never trigger asserts in libuv's guts.
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
Don't include <stdint.h>, it's not available when compiling with MSVC
2008 and we don't need it in the first place - just cast the argument
to `char *` rather than `uintptr_t`.
Fixes#893.
uv_ip6_addr() copies the address part to a temporary buffer when it
contains a link-local suffix ('<address>%<interface>'). Before this
commit, it didn't zero-terminate the address properly: it put the nul
byte at the end of the temporary buffer rather than at the end of the
address string, meaning the buffer looked like this:
<address> <garbage> '\0'
Fixes the following valgrind warning:
==16170== Conditional jump or move depends on uninitialised value(s)
==16170== at 0x43602C: inet_pton6 (inet.c:228)
==16170== by 0x435CE1: uv_inet_pton (inet.c:163)
==16170== by 0x436FD0: uv_ip6_addr (uv-common.c:175)
==16170== by 0x434717: test_ip6_addr_scope (test-ip6-addr.c:89)
==16170== by 0x43455B: call_iface_info_cb (test-ip6-addr.c:45)
==16170== by 0x43462B: foreach_ip6_interface (test-ip6-addr.c:59)
==16170== by 0x434791: run_test_ip6_addr_link_local (test-ip6-add
==16170== by 0x4061E8: run_test_part (runner.c:396)
==16170== by 0x404F4B: main (run-tests.c:58)
==16170==
==16170== Conditional jump or move depends on uninitialised value(s)
==16170== at 0x4C2AD8A: __GI_strchr (mc_replace_strmem.c:224)
==16170== by 0x435ECB: inet_pton6 (inet.c:231)
==16170== by 0x435CE1: uv_inet_pton (inet.c:163)
==16170== by 0x436FD0: uv_ip6_addr (uv-common.c:175)
==16170== by 0x434717: test_ip6_addr_scope (test-ip6-addr.c:89)
==16170== by 0x43455B: call_iface_info_cb (test-ip6-addr.c:45)
==16170== by 0x43462B: foreach_ip6_interface (test-ip6-addr.c:59)
==16170== by 0x434791: run_test_ip6_addr_link_local (test-ip6-add
==16170== by 0x4061E8: run_test_part (runner.c:396)
==16170== by 0x404F4B: main (run-tests.c:58)
Fixes#890.
Include <errno.h> and <stdlib.h>. They're being pulled in implicitly
on OS X but apparently that's not the case with iOS builds.
Build breakage introduced in 5ff6f85 by yours truly. Mea culpa.
Fixes#885 and #891.
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.
This effectively undoes the following commits:
a97685e build: add automake serial-tests version check
e4c1483 build: serial-tests was added in automake v1.12
After much trial and error I've come to the conclusion that you cannot
reliably test for the automake version inside configure.ac itself.
Feature checks (testing for the presence of macros with m4_ifdef) is
not reliable when the macro is "lazy-loaded" by aclocal: m4 won't see
its definition unless it's actually used in configure.ac, hence checking
for obsolete macros like AM_ENABLE_MULTILIB and AM_WITH_REGEX is not a
reliable proxy for the automake version - both are are lazy-loaded.
That's why this commit moves the version check to autogen.sh, creates
a m4 file with automake options on the fly and includes that in
configure.ac.
Thank you, automake maintainers, for making hard what should be easy.
That's an hour of my life I won't be getting back!
The fsevents watcher thread only needs a minimal amount of stack space
in order to run. Restrict its stack size so there's more address space
left for the libuv user.
* 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.
Fixes the following warning:
src\uv-common.c(476): warning C4715:
'uv__getaddrinfo_translate_error' : not all control paths return
a value
The function never returns - the final statement is a call to abort() -
but it seems MSVC's program flow analyzer is too weak to figure that
out.
Commit a97685e added a check that tries to ascertain whether the
serial-tests option is supported by automake. It assumed that said
option was added in automake v1.11 but it turns out that's wrong, it
wasn't added until v1.12. Update the check.
Of course, none of this would have been necessary if the automake people
had simply added a macro that tells you if serial-tests is supported or
not.
The serial-tests directive was added in automake v0.11. Add an ad-hoc
version check to find out if it's safe to enable. Fixes the autotools
build with older versions of automake.
Should fix the build after 96f32a2 inadvertently broke it.
There is no snprintf() on Windows because, hey, it's a C99 addition
and the people from Redmond, WA are still firmly stuck in 1989.
