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.
`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.
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.
This is the libuv side of the fix for Node's cluster module on Windows.
https://github.com/joyent/node/issues/7691
Windows and Unix return certain socket errors (i.e. EADDRINUSE) at
different times: bind on Windows, and listen on Unix.
In an effort to hide this difference, libuv on Windows stores such
errors in the bind_error field of uv_tcp_t, to defer raising it at
listen time.
This worked fine except for the case in which a socket is shared in
a Node cluster and a bind error occurs.
A previous attempt to fix this (
d1e6be14603da36fe00e
) was flawed becaused in an attempt to relay the error at the JS level
it caused the master to start accepting connections.
With this new approach, libuv itself is relaying the bind errors,
providing for a uniform behavior of uv_tcp_listen.
After 41891222bc landed it's possible that uv__udp_sendmsg is called
even if there are no pending write nor write completed requests:
1. User calls uv_udp_send and the request is sent immediately. The
request is the added to the completed queue and we 'feed' the uv__io
handle so that we process the completed request in the next
iteration.
2. User calls uv_udp_send again but the request is not completed
immediately, so it's queued in the write_queue.
3. The uv__io handle gets a UV__POLLOUT event and uv__udp_sendmsg is
run, which completes the send request and puts it in the
write_completed_queue. Afterwards, uv__udp_run_completed is executed
and the write_completed queue is drained.
4. At this point, the uv__io handle was made pending in step 3, in
uv__udp_sendmsg, but we no longer have requests to write or to complete,
so we skip processing.
Only these functions will trigger an implicit binding of a UDP handle:
- uv_udp_send
- uv_udp_recv_start
- uv_udp_set_membership
All other functions will return UV_EBADF in case the socket was not
bound.
Note: currently the socket is created and bound at the same time. This
may change in the future.
The PATH-parsing code for windows erroneously contained an infinite
loop when the PATH started with a leading semicolon. Each iteration of
the loop usually bumped over the separator, but if the first character
was a semicolon then it would never skip it, causing the infinite
loop.
Closes#909
Add UV_UDP_REUSEADDR flag instead, which can be passed to uv_udp_bind.
If the udp handle is unbound when uv_udp_set_memberhsip or
uv_udp_set_multicast_interface is called, the handle will be bound with
UV_UDP_REUSEADDR set.
If the same file description is open in two different processes, then
closing the file descriptor is not sufficient to deregister it from the
epoll instance (as described in epoll(7)), resulting in spurious events
that cause the event loop to spin repeatedly. So always explicitly
deregister it.
Fixes#1099.
Conflicts:
test/test-spawn.c
Introduce `int uv_pipe_pending_count(uv_pipe_t*)` and
`uv_handle_type uv_pipe_pending_type(uv_pipe_t*)`. They should be
used in IPC pipe's read cb to accept incoming handles:
int count = uv_pipe_pending_count(pipe);
int i;
for (i = 0; i < count; i++) {
uv_handle_type type = uv_pipe_pending_type(pipe);
/* ... */
uv_accept(...);
}
These functions supersede uv_loop_new and uv_loop_delete.
uv_loop_init initialized a user allocated loop and uv_loop_close
removes all associated resources a loop uses after it has finished
execution.
uv_loop_new and uv_loop_delete are now deprecated.
If the same file description is open in two different processes, then
closing the file descriptor is not sufficient to deregister it from the
epoll instance (as described in epoll(7)), resulting in spurious events
that cause the event loop to spin repeatedly. So always explicitly
deregister it.
Fixes#1099.
Every file descriptor opened using libuv should be automatically marked
as CLOEXEC to prevent it from leaking to a child process. Note that
since we are opening fds in a thread pool, there is a possible race
condition between `uv_spawn()` and the `open()` + `uv__cloexec()`. The
rwlock was added to avoid it.
see https://github.com/joyent/node/issues/6905
getaddrinfo_fail can sometimes take slightly longer than the default
timeout of 5000. Set its timeout to 10000 to compensate, but leave the
timeout of all other tests at the default.
Add a single TEST_ENTRY_CUSTOM hook that can be used to override task
entry defaults. Different tests can have different timeouts depending on
what is appropriate for each test. A separate TEST_OUTPUT_ENTRY hook is
no longer necessary.
In order to support per-task timeouts, the timeout field has been moved
into the task_entry_t struct. The default (5000) is now set as part of
TEST_ENTRY.
Thus allow passing the same file descriptor as the source of multiple
stdios.
Committed with the help and code parts from:
* Sam Roberts <sam@strongloop.com>
fix#1074
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).
`uv_try_write(stream, buf, size)` acts like `uv_write()`,
but without queueing actual write until UV_POLLOUT (or IOCP completion).
This is useful for doing writes using on-stack `uv_write_t` requests.
fix#1025
Fix a bug that was introduced in commit 3ee4d3f ("unix, windows:
return error codes directly") and add a regression test for good
measure.
Hat tip to Fedor for pointing out the issue.
Fixes#1007.
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
Work around an epoll quirk where it sometimes reports just the EPOLLERR
or EPOLLHUP event. In order to force the event loop to move forward,
we merge in the read/write events that the watcher is interested in;
uv__read() and uv__write() will then deal with the error or hangup in
the usual fashion.
Fixes#982.
Drops commit 3780e12 ("fsevents: support japaneese characters in path")
for being quite inapplicable to the master branch. Will be reworked
and applied in a follow-up commit.
Conflicts:
README.md
build.mk
src/unix/fsevents.c
src/unix/udp.c
There're could be a situation, where one fsevents handle gets created
and another one is destroyed simultaneously. In such cases
`fsevent_need_reschedule` will be set to 1 twice and reset only once,
leaving handle destructor hanging in uv_sem_wait().
Uses the pthread_key_{create,delete} and pthread_{get,set}specific
functions on UNIX platforms, Tls{Alloc,Free} and Tls{Get,Set}Value
on Windows.
Fixes#904.
Check that a timer that is started from a check handle gets picked up
correctly, i.e. that it influences the timeout used in the next tick
of the event loop.
Before this commit, creating an event loop, starting a timer and
calling uv_run(UV_RUN_ONCE) blocked in uv_run() until the timer
expired - but didn't actually run the timer.
The documentation in uv.h states that the status argument to the
uv_getaddrinfo() callback is either 0 or -1 but uv-unix actually
passed it the addrinfo error code. Rectify that and add a regression
test.
Fixes#754.
This commit fixes two closely related integer overflow bugs:
* Timers with a timeout > INT_MAX cause uv__next_timeout() to return
a negative value.
* Timers with very large timeouts (close or equal to ULLONG_MAX) run on
the next tick.
In both cases, clamp the values to prevent the overflow from happening.
Fixesjoyent/node#5101.
It makes the assumption that if you try to write to a localhost socket
often enough, eventually its send queue will fill up - which doesn't
happen if the machine it's running on is fast enough.
uv_guess_handle is currently squelching both fifo and all
sockets on to the UV_NAMED_PIPE type. Rather than treating
all sockets as UV_NAMED_PIPE, use getsockopt() and
getsockaddr() to determine if the socket is an AF_UNIX
stream (in which case return UV_NAMED_PIPE), or an AF_INET
stream (in which case return UV_TCP), or an AF_INET datagram
socket (in which case return UV_UDP).
Additionally, currently all other file descriptor types are
squelched to the UV_FILE type. Instead, only file descriptors
that are marked as regular files are treated as UV_FILE. All
other types (such as directories, character and block devices)
are now treated as UV_UNKNOWN_HANDLE.
Wake up the event loop with uv_async_send() when a request is cancelled.
Ensures the done_cb is run on the next tick of the event loop.
Not sending a wakeup signal results in the done_cb not getting called until
another request completes, which may be a long time coming when it's the only
request in the queue or when other requests are executing long-running jobs.
Fixes#669.
Allows for running the event loop in 3 modes:
* default: loop runs until the refcount drops to zero
* once: poll for events only once and block until one is handled
* nowait: poll for events only once but don't block if there are
no pending events
Fix a rather obscure bug where the event loop stalls when an I/O watcher is
stopped while an artificial event, generated with uv__io_feed(), is pending.
This can be used in conjuction with uv_run_once() to poll in one thread and run
the event loop's event callbacks in another.
Useful for embedding libuv's event loop in another event loop.
Currently, `uv_spawn` will set `environ` to the value of `options.env`, even if
`options.env` is `NULL`. This results in child processes for whom `environ ==
NULL`, which can cause a variety of unexpected issues.
This is a back-port of commit 1d85815 from the master branch.
Currently, `uv_spawn` will set `environ` to the value of `options.env`, even if
`options.env` is `NULL`. This results in child processes for whom `environ ==
NULL`, which can cause a variety of unexpected issues.
Demonstrates temporary event loop stall with uv-unix. The issue is that pending
requests aren't processed until the next event (I/O, timeout, etc.) happens.
See #446, #447 and #448.
Previously the only option was to create a pipe or an ipc channel. This
patch makes it possible to inherit a handle that is already open in the
parent process. There is also room for setting more than just stdin,
stdout and stderr, although this is not supported yet.
uv_timer_start() no longer returns an error when the timer is already active,
now it just updates the timer. Consistent with the uv-win implementation.
Fixes#425.
This commit changes how the event loop determines if it needs to stay alive.
Previously, an internal counter was increased whenever a handle got created
and decreased again when the handle was closed.
While conceptually simple, it turned out hard to work with: you often want
to keep the event loop alive only if the handle is actually doing something.
Stopped or inactive handles were a frequent source of hanging event loops.
That's why this commit changes the reference counting scheme to a model where
a handle only references the event loop when it's active. 'Active' means
different things for different handle types, e.g.:
* timers: ticking
* sockets: reading, writing or listening
* processes: always active (for now, subject to change)
* idle, check, prepare: only active when started
This commit also changes how the uv_ref() and uv_unref() functions work: they
now operate on the level of individual handles, not the whole event loop.
The Windows implementation was done by Bert Belder.
