When multiple bufs are specified, overlapped needs to be advanced
manually between each write. Without this, each buf will be written
to the same position (if offset is specified.)
ReadFile() automatically advances, but WriteFile() does not.
uv_interface_addresses was using the linked list pointed to by
the FirstPrefix member of IP_ADAPTER_ADDRESSES in order to compute the
network prefix / network mask.
This was flawed in several ways:
- FirstPrefix can be NULL, and we would crash.
- On Windows Vista and later, the prefix list includes three IP adapter prefixes
for each IP address assigned to the adapter. We were assuming a 1:1 mapping
with the unicast address list.
- Even on Windows versions (i.e. XP) where the prefix list is supposed to have
one and only one element for each unicast address, the order of the two lists
is not guaranteed to be the same.
This fix was inspired and adapted from a commit in the Chromium project:
https://codereview.chromium.org/25167002/diff/6001/net/base/net_util_win.cc
See MSDN article for reference:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366058(v=vs.85).aspx
Excerpt from MSDN below:
In addition, the linked IP_ADAPTER_UNICAST_ADDRESS structures pointed to
by the FirstUnicastAddress member and the linked IP_ADAPTER_PREFIX
structures pointed to by the FirstPrefix member are maintained as separate
internal linked lists by the operating system. As a result, the order of
linked IP_ADAPTER_UNICAST_ADDRESS structures pointed to by the
FirstUnicastAddress member does not have any relationship with the order
of linked IP_ADAPTER_PREFIX structures pointed to by the FirstPrefix member.
On Windows Vista and later, the linked IP_ADAPTER_PREFIX structures pointed to
by the FirstPrefix member include three IP adapter prefixes for each IP address
assigned to the adapter. These include the host IP address prefix, the subnet
IP address prefix, and the subnet broadcast IP address prefix. In addition, for
each adapter there is a multicast address prefix and a broadcast address prefix.
It seems that epoll_wait is implemented in glibc in terms of epoll_pwait and
new architectures (like arm64) do not implement the epoll_wait syscall at all.
So if epoll_wait errors with ENOSYS, just call epoll_pwait.
- Remove the UV_HANDLE_ACTIVE flag. It's a duplicate from
UV__HANDLE_ACTIVE, which was used solely on timers and loop watchers.
- Avoid duplicated code when running timers by stopping the handle and
rearming it with the repeat time, thus having a single place where the
timers are added and removed to and from the RB tree, respectively.
`fd_set`s are way too small for `select()` hack when stream's fd is
bigger than 1023. Make `fd_set`s a part of `uv__stream_select_t`
structure.
fix#1461
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.
If the connect wouldn't go off (no such tcp remote or any other failure),
the subsequent writes made would not be called. Now we call the writes
in the queue with ECANCELED if the connect fails.
Fix#1432
This fixes a SmartOS specific issue that happens when reading from
a stream that is the reading end of a pipe that has been closed by
the parent process.
In this case, a UV__POLLHUP event would be set on the stream and would
prevent the event loop from closing it. As a result, the event loop
would think there are stil handles open, and leave the process
hanging.
Fixes#1419.
Support all possible types on Unix, and files, directories and links on
Windows. Some systems (hello SunOS!) don't have the d_type field on struct
dirent, so mark them as UV_DIRENT_UNKNOWN.
Introduce:
int uv_fs_readdir_next(uv_fs_t* req, uv_dirent_t* ent);
`uv_fs_readdir()` is not returning a file names list in `req->ptr`
anymore, the proper way to gather them is to call `uv_fs_readdir_next()`
in a callback.
This implements locking around the blocking call to ReadFile to get
around a Windows kernel bug where a blocking ReadFile operation on a
stream can deadlock the thread. This allows uv_read_stop to immediately
cancel a pending IO operation, and allows uv_pipe_getsockname to
"pause" any pending read (from libuv) while it retrieves the
sockname information.
If unsupported by the OS (pre-Vista), this reverts to the old
(e.g. deadlock-prone) behavior
Closes#1313
The unix and windows process implementations diverge in their behavior
when dealing with subprocesses that are spawned with a relative path.
With unix the *child's* PATH environment variable is read, whereas
with windows the *parent's* environment variable is read.
This commit brings the two implementation in line with respect to
their behavior of reading PATH by having both read the *child's* PATH
environment variable. This involves looking into the user-provided
environment on windows and extracting the PATH variable specifically
so it can be inspected later on.
