Remove the TODO that says to batch up kevent(EV_DELETE) system calls.
It's unduly complicated in case of errors.
If you pass an out array to kevent(), it will store error records that
tell you which file descriptor caused the error but it also stores new
events in the array, complicating state management.
If you don't pass an out array, it simply doesn't tell you anything
except that _something_ failed. Optimistically trying batch deletion
and falling back to one-by-one deletion is probably possible but is
something of a deoptimization and also feels somewhat dangerous.
macOS has a mostly-undocumented kevent_qos() system call that accepts a
KEVENT_FLAG_ERROR_EVENTS flag that fixes the first problem but that of
course isn't portable.
Long story short, it seems like too much hassle for too little payoff.
Libuv has been doing one-by-one deletion for over a decade now and no
one complained about performance so far so let's just stick with that.
Another thread can change the working directory between calls to
GetCurrentDirectoryW().
The first call was used to determine the size of the buffer to use in
the second call. Retry if the reported size does not match the expected
size because the buffer's contents is undefined in that case.
uv_exepath() wrote the nul byte *after* the end of the buffer. It's not
necessary to write said nul byte in the first place because that was a
workaround for a bug in the Windows XP version of GetModuleFileName().
Fix uv_cwd() in the same fashion, it doesn't need the nul byte either.
Fixes: https://github.com/libuv/libuv/issues/3691
After analysis of many real-world programs I've come to conclude that
accepting in a loop is nearly always suboptimal.
1. 99.9% of the time the second accept() call fails with EAGAIN, meaning
there are no additional connections to accept. Not super expensive
in isolation but it adds up.
2. When there are more connections to accept but the listen socket is
shared between multiple processes (ex. the Node.js cluster module),
libuv's greedy behavior necessitated the UV_TCP_SINGLE_ACCEPT hack
to slow it down in order to give other processes a chance.
Accepting a single connection and relying on level-triggered polling to
get notified on the next incoming connection both simplifies the code
and optimizes for the common case.
This was a kludge for a bug in old versions (API level <= 16) of the
Android SDK.
The os390 port had a build dependency on the file but does not actually
use it so that too has been removed.
Split this off from endgame, so that it can be handled separately and
earlier, rather than trying to detect inside endgame which case we are
in. There appear to be some race conditions on the `handle` field still
however, which this does not yet attempt to address.
Some setsockopt() implememantations may return with errno of EINVAL
when the socket has been shut down already, as documented in the
Open Group Specifications Issue 7, 2018.
When this happens, reset errno and continue to mark the socket closed
and handle any callback.
Port the changes made to AIX and other unix systems in #611 to z/OS.
Defers the signal watcher that is used for process management until
after the dispatch of regular i/o watchers.
Refs: https://github.com/libuv/libuv/pull/611
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
Once the write queue is empty, we can fire the event immediately,
without needing a lot of syscalls and then waiting for the kernel to
feed us the event on the next tick. This also makes it more similar to
how it would behave if there was a write still in the queue also, which
we dispatch later in the same event loop iteration, then drain.
EINTR is explicitly documented as a possible error code of tcsetattr().
The documentation for tcgetattr() is silent on the subject but better
safe than sorry.
Fixes: https://github.com/libuv/libuv/issues/3645
The UV_ECANCELED codepath had an incorrect comment, and the
implementation was generally less robust (for example, not checking if
`cb` was NULL), so we can merge these codepaths for cleaner code.
The errno value is only meaningful if bind() fails and returns -1.
Some bind() implementations may return success but modify errno value
internally, like the socket_wrapper library used by the Samba testsuite.
This fixes an early exit bug in z/OS implementation of epoll_wait(),
resulting in some file events not being correctly captured.
The problem is that reventcount should only be incremented by 1, because
_NFDS counts as 1 even for fds with multiple revents set.
Also makes a few minor improvements to remove redundant checks.
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
Fixes an issue where under certain conditions, dynamically allocated
ip addresses, strings, and buffers were either leaking memory, being
incorrectly freed, or not performing error checks.
Also fixes an issue where the uv_interface_address_t struct was not
correctly initialized to 0, so use calloc() instead of malloc().
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
Use SIOCGIFNETMASK ioctl to retrieve the netmask for IPv4. However, this
approach is not supported for IPv6.
For IPv6 netmask, z/OS currently only provides the prefix length through
the __nif6e_prefixlen in __net_ifconf6entry_t struct, but this can be
used to calculate the IPv6 netmask similar to android implementation.
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
On z/OS, the interface address name contains EBCDIC and may be padded
with whitespaces. The whitespace padding needs to be trimmed, and the
interface address name needs to be converted from EBCDIC to ASCII.
Co-authored-by: John Barboza <jbarboza@ca.ibm.com>
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
On z/OS, fs events are implemented by registering file interest. When
closing a fs event handle, it's possible that a change notification has
already been generated. In that case, the attempt to unregister file
interest will fail with EALREADY. This will result in the fs event being
delivered even though the handle is closing, which should not happen.
Fixes: https://github.com/libuv/libuv/issues/3601
On z/OS, EPERM is returned if the process being killed is a zombie.
However, this shouldn't be treated as an error, so return 0 instead.
Co-authored-by: Muntasir Mallick <mmallick@ca.ibm.com>
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
On NetBSD with libuv 1.44.1 we see that cmake occasionally hangs
waiting for a child process to exit, with libuv waiting forever for
`kevent` to deliver more events that never come. The child process has
already exited and is waiting to be collected with `waitpid`.
The hang occurs when the batch of events returned by one call to
`kevent` contains both a EVFILT_READ event for an fd and a later
EVFILT_PROC record for the PID with the same value as the earlier fd.
What happens is that `uv__platform_invalidate_fd` is called to
invalidate events later in the same batch for the fd, but
`uv__platform_invalidate_fd` invalidates the later EVFILT_PROC event
too because it sees the same "ident" value and does not check the
"filter" value to differentiate "ident" values that refer to fds vs.
"ident" values that refer to PIDs.
Add a check for the "filter" value to avoid confusing these two
different kinds of event "ident" values.
Previously, Windows would always defer event processing to the loop
after they were received. This could cause confusion for users who were
using prepare and idle callbacks, as seen from this bug in nodejs[^1] and
this discussion in libuv[^2], and even some discrepancies in the libuv
tests too[^3].
[^1]: https://github.com/nodejs/node/pull/42340
[^2]: https://github.com/libuv/libuv/discussions/3550
[^3]: See change to test-spawn.c in this PR
So rather than declare those usages to be wrong, we change libuv to meet
those users expectations.
Replaces: https://github.com/libuv/libuv/pull/3585
If `uv_close` was called while a connect was pending, we would fail to
release the resources for the connection, since we had not yet set the
type of the struct.
Fix a thread data-race on slow connect path code: only permitted to
write to `req` on threads, as anything else causes data race
corruption.
There seemed be a small variety of other resource management bugs in
edge cases, which turned out to make this a lot larger than initially
expected.
Refs: https://github.com/libuv/libuv/pull/3598#issuecomment-1111513567
Use MSG_CMSG_CLOEXEC on Unix-y platforms that support it (all except
macOS and SunOS spawn.)
Remove the feature test for Linux. Libuv's kernel baseline is 2.6.32
and MSG_CMSG_CLOEXEC was added in 2.6.23.
macOS 10.15 has a bug where configuring the working directory with
posix_spawn_file_actions_addchdir_np() makes posix_spawnp() fail with
ENOENT even though the executable is spawned successfully.
Co-authored-by: Ben Noordhuis <info@bnoordhuis.nl>
When the watched file is moved or removed, or an editor (e.g. vim)
renames then creates the file, the __rfim_event 156 occurs. This is an
undocumented event that should not happen, but register it as UV_RENAME
for now since it is functionally equivalent.
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
`rename()` can be used to rename a file path via _RFIM_UNLINK. So
register it as a UV_RENAME event.
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
The file is implicitly unregistered when the change notification is
sent, only one notification is sent per registration. So we need to
re-register interest in a file after each change notification we
receive.
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
On illumos and Solaris, fs events are implemented with
PORT_SOURCE_FILE type event ports. These are one-shot so
need re-arming each time they fire. Once they are armed
and an event occurs, the kernel removes them from the current
cache list and puts them on an event queue to be read by
the application.
There's a window in closing one of these ports when it could
have triggered and be pending delivery. In that case, the
attempt to disarm (dissociate) the event will fail with ENOENT
but libuv still goes ahead and closes down the handle. In
particular, the close callback (uv_close() argument) will be
called but then the event will subsequently be delivered if
the loop is still active; this should not happen.
This commit adds the support for a custom strtok implementation, which
is reentrant. On some systems strtok_r or strstep is available for that
purpose; however, since these are an extension, it is difficult to
control if it will be available on every supported system.
Remove the `TARGET_OS_IPHONE` ifdef to include posix spawn headers for
iOS build. Previously https://github.com/libuv/libuv/pull/3257
introduced posix spawn with \_\_APPLE\_\_ platform only, which resulted
in a number of spawn related definitions not found for iOS (such as
`uv__posix_spawn_fncs_tag`).
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
Although the change remapped the error code to the correct one, a lot of
code already depends on the incorrect one, so it's not worth the
breakage.
This reverts commit 04a35efe69.
Refs: https://github.com/nodejs/node/pull/42340
Signed-off-by: Darshan Sen <raisinten@gmail.com>
