Indicate that it can (and should) also be closed, currently it's not
"special" in any way.
PR-URL: https://github.com/libuv/libuv/pull/147
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
libuv requires that the socket/fd is in non-blocking mode, so do it
internally so the user doesn't need to write platform specific code to
do so.
This also makes the API consistent with uv_{tcp,udp,pipe}_open, since
it's not required to pass the fd in non-blocking mode there either.
PR-URL: https://github.com/libuv/libuv/pull/136
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Changes since version 1.2.0:
* unix: remove unused dtrace file (Saúl Ibarra Corretgé)
* test: skip TTY select test if /dev/tty can't be opened (Saúl Ibarra
Corretgé)
* doc: clarify the behavior of uv_tty_init (Saúl Ibarra Corretgé)
* doc: clarify how uv_async_send behaves (Saúl Ibarra Corretgé)
* build: make dist now generates a full tarball (Johan Bergström)
* freebsd: make uv_exepath more resilient (Saúl Ibarra Corretgé)
* unix: make setting the tty mode to the same value a no-op (Saúl Ibarra
Corretgé)
* win,tcp: support uv_try_write (Bert Belder)
* test: enable test-tcp-try-write on windows (Bert Belder)
* win,tty: support uv_try_write (Bert Belder)
* unix: set non-block mode in uv_{pipe,tcp,udp}_open (Ben Noordhuis)
The contract specifies that the file descriptor should already be in
non-blocking mode before passing it to libuv.
However, node users don't really have an opportunity to do so, never
mind the fact that the call to uv_pipe_open() or uv_tcp_open() is an
implementation detail that most users won't be aware of.
Let's be nice and set the non-blocking flag explicitly. It's a cheap
operation anyway.
Fixes: https://github.com/libuv/libuv/issues/124
PR: https://github.com/libuv/libuv/pull/134
Reviewed-by: Saúl Ibarra Corretgé <saghul@gmail.com>
The mode argument is an enum now and the signedness of an enum is
implementation-defined when it doesn't have negative members.
Cast it to int in the comparison to tty->mode because the latter is
still an int.
PR: https://github.com/libuv/libuv/pull/134
Reviewed-by: Saúl Ibarra Corretgé <saghul@gmail.com>
All windows console writes are synchronous anyway, so there's no reason
for uv_try_write() to do nothing.
PR: https://github.com/libuv/libuv/pull/127
Reviewed-by: Saúl Ibarra Corretgé <saghul@gmail.com>
Autotools tries to figure out what's necessary to create a tarball through
included files in Makefile.am. Since libuv has conditionals based on target OS
as well as additional samples/documentation, extra_files needs to include these.
Also, add the result of make dist to gitignore.
PR-URL: https://github.com/libuv/libuv/pull/118
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Move compile-time flags that are not platform-specific defines to
configure.ac where they can be properly feature-detected.
PR-URL: https://github.com/libuv/libuv/pull/24
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Don't check if -Wno-dollar-in-identifier-extension is supported in the
autotools build; that flag was only necessary on OS X and only when the
dtrace probes were enabled (because dtrace(1) generates identifiers with
sigils in them). The probes were removed in commit cb51400, making the
check unnecessary.
PR-URL: https://github.com/libuv/libuv/pull/24
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Turn on -Wall -Wextra -Wno-unused-parameter, just like we do in gyp
builds.
PR-URL: https://github.com/libuv/libuv/pull/24
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
It should fix the following build error with old autoconf/automake
versions:
Makefile.am:24: Libtool library used but `LIBTOOL' is undefined
Makefile.am:24: The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
Makefile.am:24: to `configure.ac' and run `aclocal' and `autoconf'
again.
Fixes: https://github.com/libuv/libuv/issues/111
PR-URL: https://github.com/libuv/libuv/pull/113
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The serial-tests option is available in automake v1.12, not v0.12.
PR-URL: https://github.com/libuv/libuv/pull/113
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
I'm not 100% sure whether the behavior of readlink() with size=0 is
well-defined on Solaris; it can return either 0 or fail with EINVAL.
POSIX is not explicit about the mandated behavior.
This commit adds a little caution and makes it skip the readlink()
call when size=1 and simply writes the terminating zero byte.
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
uv_exepath() should write as much as possible to the output buffer.
In the case of size=1, skip the call to readlink() because it will
fail with EINVAL; just write the terminating zero byte.
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Write as much of the path as possible to the output buffer. Before this
commit, passing in a buffer that was too small to hold the result failed
with a UV_EINVAL error.
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Passing a buffer that was too small to hold the result made it fail
with UV_EPERM because the -1 status code from _NSGetExecutablePath()
was returned unmodified to the caller.
This commit rewrites uv_exepath() to:
1. Not allocate heap memory, and
2. Not clobber the result buffer on error, and
3. Handle _NSGetExecutablePath()'s and realpath()'s idiosyncracies, and
4. Store as much of the path in the output buffer as possible, don't
fail with an error. Makes it behave the same as other platforms.
The result is always zero-terminated.
Fixes: https://github.com/libuv/libuv/issues/103
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Make the behavior of a call to uv_exepath() with a size argument of zero
consistent with the Windows implementation where it returns UV_EINVAL.
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The fix from commit 269ff0be is wrong in that it sniffs system headers
to determine if preadv() and pwrite() are supported.
It breaks the fs_write_multiple_bufs test on one of my ARM systems;
its glibc has preadv() and pwritev() wrappers but its kernel has no
support for the corresponding system calls.
Simply try the system call and fall back to a normal read or write
loop if not supported. Move the no_preadv and no_pwritev variables
around to squelch two -Wpedantic warnings about mixing declarations
with code.
PR-URL: https://github.com/libuv/libuv/pull/90
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Using a static thread local variable to store the thread handle causes
crashes on Windows XP/2003 when libuv is loaded as a dynamic library.
With this patch, a TLS slot is allocated dynamically.
PR-URL: https://github.com/libuv/libuv/pull/82
Reviewed-By: Bert Belder <bertbelder@gmail.com>
This reverts commit a9e95a33bc.
This seems to cause regressions in the test suite when IPv6 is disabled.
As optimizations go, it's a very minor one so let's not spend too much
effort trying to track down the cause of the regressions but revert the
change before it makes its way into a release.
PR-URL: https://github.com/libuv/libuv/pull/92
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Fix spawn_reads_child_path when executed as `test/run-tests` or
`make check`:
1. `make check` builds a dynamic libuv.so or libuv.dyld by default.
2. spawn_reads_child_path spawns a new instance of the test runner
by consulting uv_exepath() and executing the result.
3. `test/run-tests` is normally a shell script that sets up
DYLD_LIBRARY_PATH or LD_LIBRARY_PATH before executing the
real test runner in `test/.libs`.
4. uv_exepath() (corectly) returns the path of the binary in
`test/.libs`. The binary is linked against libuv.so but that
library is not on any of the default linker paths; and if it is,
it's almost certainly the wrong version.
5. Ergo, carry over the value of the (DY)LD_LIBRARY_PATH environment
variable into the environment of the child process so that the
dynamic linker knows where to find the library.
Alternatively, we could link the test runner statically against libuv.a
but that breaks `make check` when configured with `--disable-static`.
Fixes: https://github.com/libuv/libuv/issues/85
PR-URL: https://github.com/libuv/libuv/pull/91
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
