autotools support only, gvp does not support kfreebsd detection.
PR-URL: https://github.com/libuv/libuv/pull/960
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
- zos: disable test cases not applicable
- zos: build options
- zos: semaphore implementation
- zos: use compare and swap builtins
- zos: struct rusage not the same as other platforms
- zos: backlog<=0 produces undefined behaviour
Will redefine backlog in the following way
* if backlog == 0, set it to 1
* if backlog < 0, set it to SOMAXCONN
- zos: define IMAXBEL as empty flag and implement uv__tty_make_raw
- zos: use udp multicast operations from aix
- zos: ESC in ebcdic
- zos: use LIBPATH for dynamic linker path
- zos: uv_udp_set_ttl only works for ipv6
- zos: increase pthread stack size by factor of 4
- zos: return ENODEV instead of ENXIO errors for setsockopt
- zos: use uv_cond_init the same way as aix
- test: enable oob test for zos
- zos: return EINVAL for zos error code EOPNOTSUPP
PR-URL: https://github.com/libuv/libuv/pull/937
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
It's just an indicator that the operation will happen later, so return
success.
PR-URL: https://github.com/libuv/libuv/pull/892
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
It can happen that the `parent` end of the `signal_pipe` is given a
STDIO file descriptor, so closing it using `uv__close` fails.
This problem is happening when running the `spawn_closed_process_io`
test in `SmartOS`. The reason being that when creating a socketpair in
`uv__process_init_stdio`, the `Illumos` implementation uses 3 sockets:
one is used as a listener, and the other 2 represent both ends of the
pipe. The listener socket is closed once the pipe is created. In the
test, the listener socket is assigned to the `0` fd, as it is the
first free fd in the system. So the fd `0` remained free after the call
to `socketpair`. Afterwards, when creating the `signal_pipe`, the fd `0`
is being assigned again, so closing it with `uv__close` made the test
fail. This issue is not happening in the other unixes because
`socketpair` doesn't use 3 fd's, but only 2.
To solve the issue, a new `uv__close__nocheckstdio()` function has been
added and used.
PR-URL: https://github.com/libuv/libuv/pull/796
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
uv__open_cloexec returns either the fd or a libuv error, which is -errno
on Unix, not -1.
PR-URL: https://github.com/libuv/libuv/pull/760
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
If an API function returns UV_ENOBUFS make sure we count the terminating
null, which we need space for. In case of success the null byte is not
included in the count, but the buffer *is* null terminated.
PR-URL: https://github.com/libuv/libuv/pull/690
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
The `__FreeBSD__` macro is not defined by default on OSX, and building
with `-Wundef` will cause a warning to be emitted. This change makes
sure that the macro is only used if defined, removing the warning.
PR-URL: https://github.com/libuv/libuv/pull/710
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Remove restriction to Android API level >= 21, now libuv can be used with
Android API level at least 14.
Direct use of getpwuid_r function resulted in linker errors in applications
were built against API level below 21. That function was 'officially'
introduced in Android API level 21, but it exists in libc beginning from API
level at least 14.
So try to get a pointer to getpwuid_r at runtime using dlsym when building
libuv with API level < 21.
PR-URL: https://github.com/libuv/libuv/pull/633
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Like the previous commit, but this time for UNIX platforms other than
Linux.
As far as I have been able to establish, dup2 and dup3 never return
EINTR on OS X and FreeBSD. Even if other platforms do return EINTR,
it's probably still better not to retry because it's unspecified
whether the file descriptor has been closed.
Fixes: https://github.com/libuv/libuv/issues/462
PR-URL: https://github.com/libuv/libuv/pull/608
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Retrying seems like a bad idea in a multi-threaded program because the
man page leaves it unspecified whether the file descriptor is closed
after EINTR.
It's probably an academic issue because as far as I have been able to
establish by checking the kernel sources, dup2 and dup3 never actually
return EINTR. For dup3, this appears to have been the case since its
introduction in v2.6.27; for dup2, it goes back to at least v2.6.18.
Fixes: https://github.com/libuv/libuv/issues/462
PR-URL: https://github.com/libuv/libuv/pull/608
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
On some embedded devices (arm-linux-uclibc based ip camera),
sysconf(_SC_IOV_MAX) can not get the correct value. The return
value is -1 and the errno is EINPROGRESS. Degrade the value to 1.
PR-URL: https://github.com/libuv/libuv/pull/573
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
All uses of QUEUE_SPLIT in libuv split the list at the head so introduce
a QUEUE_MOVE macro that automates that.
PR-URL: https://github.com/libuv/libuv/pull/565
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This allows writing and reading any amount of buffers,
regardless of what IOV_MAX may be defined as.
It also moves the IOV_MAX test from stream to core.
This is based on the excellent work of @bwijen in #269.
Refs: https://github.com/libuv/libuv/pull/269
PR-URL: https://github.com/libuv/libuv/pull/448
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Use the same code path as FreeBSD does.
PR-URL: https://github.com/libuv/libuv/pull/399
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Some systems, FreeBSD for example, may return negative values.
sysconf() returns a long, which was being converted to a size_t.
This conversion lead to large allocations, and subsequent out of
memory failures. This commit checks the long value returned by
sysconf() properly, and uses a default value of 4096 if a negative
number is returned.
PR-URL: https://github.com/libuv/libuv/pull/389
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
If pending I/O callbacks were ran before polling, do a zero timeout
poll.
PR-URL: https://github.com/libuv/libuv/pull/58
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The modes are not meant to be combined, and doing so may hide problems
in the future.
PR-URL: https://github.com/libuv/libuv/pull/58
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This aligns the behavior with the Windows implementation.
PR-URL: https://github.com/libuv/libuv/pull/63
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Fix various typos and spelling mistakes in comments.
Does not affect any code, just changes comments.
PR-URL: https://github.com/libuv/libuv/pull/17
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The existing probes, all two of them, cause a great deal of pain for
people trying to build libuv on Linux because of SystemTap's dtrace(1)
utilitity not understanding the -xnolibs flag.
We could hack around that but it's easier to just remove the probes:
they are largely useless and unused while still needing a lot of
supporting infrastructure. This commit removes 200 lines of code
and configuration.
Refs joyent/libuv#1478.
Returns the platform specific file descriptor for handles that are
backed by one. The datatype is abstracted as uv_os_fd_t, which maps to
int on Unices and HANDLE on Windows.
Users can use this function to set specific socket options, for example,
in a non portable way.
This function is essentially a shotgun, you better be careful with
whatever you do with it, don't blame me if you used it to get the fd of
a stream, close it yourself and expect things to Just Work.
Reopen the file descriptor when it refers to a tty. This lets us put the
tty in non-blocking mode without affecting other processes that share it
with us.
This brings back commit 31f9fbc, which was reverted in 20bb1bf. The OSX
select trick is working now.
Original patch by @bnoordhuis
Useful to know when the the event loop is empty, this can't be done with
uv_run() without possibly blocking, or running some events (which might
empty the event loop as a side-effect).
Set the close-on-exec flag on file descriptors that we've received with
recvmsg() so we don't leak them when calling fork() afterwards.
On Linux, we use the MSG_CMSG_CLOEXEC flag when supported (2.6.23 and
up.)
On older Linux versions and other platforms, we walk the received file
descriptors and set the close-on-exec flag for each fd manually. That
won't entirely avoid race conditions when other threads call fork() or
clone() but at least we're less likely to leak file descriptors now.
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
On some systems, clock_gettime(CLOCK_MONOTONIC) is only serviced from
the vDSO when the __vdso_clock_gettime() wrapper is confident enough
that the vDSO timestamp is highly accurate. When in doubt, it falls
back to making a traditional SYS_clock_gettime system call with all
the overhead that entails.
While a commendable approach, it's overkill for our purposes because we
don't usually need high precision time. That's why this commit switches
to CLOCK_MONOTONIC_COARSE for low-precision timekeeping, provided said
clock has at least a one millisecond resolution.
This change should eliminate the system call on almost all systems,
including virtualized ones, provided the kernel is >= 2.6.32 and glibc
is new enough to find and parse the vDSO.
Ensure that close() system calls don't close stdio file descriptors
because that is almost never the intention.
This is also a partial workaround for a kernel bug that seems to affect
all Linux kernels when stdin is a pipe that gets closed: fd 0 keeps
signalling EPOLLHUP but a subsequent call to epoll_ctl(EPOLL_CTL_DEL)
fails with EBADF. See joyent/node#6271 for details and a test case.
