Cheking if the loop is alive is covered in the while loop afterwards.
Also, the stop flag will be cleared if necessary, which didn't happen
before this patch.
Mea culpa, the previous commit added another ERROR_FILENAME_EXCED_RANGE
case to the switch statement in uv_translate_sys_error(). This commit
fixes up the build error.
Make it possible to call uv_tty_reset_mode() from inside a signal
handler. The primary motivation is to make it possible to restore
the TTY from inside a SIGINT or SIGTERM signal handler.
Fixes#954.
Before this commit, multiple event loops raced with each other when a
SIGCHLD signal was received. More concretely, it was possible for
event loop A to consume waitpid() events that should have been
delivered to event loop B.
This commit addresses that by doing a linear scan over the list of
child processes. An O(n) scan is not terribly efficient but the
actual performance impact is not measurable in a benchmark that spawns
rounds of several thousands instances of /bin/false. For the time
being, this patch will suffice; we can always revisit it later.
Fixes#887.
Before this commit, uv_uptime() returned the nanoseconds as the
fractional part of the uptime. It's a bit inconsistent with the
output on other platforms because those only return whole seconds
(with the possible exception of Windows.)
This commit changes linux-core.c to only return whole seconds.
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().
This commit reverts the following commits:
983fa68 darwin: fix 10.6 build error in fsevents.c
684e212 fsevents: use shared FSEventStream
ea4cb77 fsevents: FSEvents is most likely not thread-safe
9bae606 darwin: create fsevents thread on demand
Several people have reported stability issues on OS X 10.8 and bus
errors on the 10.9 developer preview.
See also joyent/node#6296 and joyent/node#6251.
The cleanup-after-error code path in uv_spawn() was closing file
descriptors indiscriminately. Only close file descriptors that we
created ourselves, not the ones that are passed in by the user.
Fixesjoyent/node#6297.
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.
It turns out that node.js relies on the blocking behavior of pipes in
some cases, notably when forking worker processes. Reopens#941.
This reverts commit 8fe4ca686b.
Don't rely on the caller to set the O_NONBLOCK flag on the file
descriptor.
Prevents sporadic stalls when the file descriptor is in blocking mode
and exactly as many bytes are read as there are available; in that case,
libuv will try to read again and block. Node.js was guilty of this.
Fixes#941.
Work around an 'initializer element is not constant' build error in
src/unix/fsevents.c by turning the const int flags into #defines.
Only an issue on OS X 10.6 due to the old compiler it uses.
Fixes#908.
This is a back-port of commit 82f2472 from the master branch.
Until now we assumed that _open_osfhandle() would set _doserrno on
failure. This assumption was very wrong in one obvious case, namely when
the CRT file descriptor table would fill up. In that case errno is set
to EMFILE, but GetLastError() returns zero - which makes sense because
it's not a win32 error but rather a CRT problem.
Before, when the user passed an invalid paramter to uv_fs_open, libuv
would detect this and call SET_REQ_RESULT to set the result value to -1.
SET_REQ_RESULT then stored whatever error code was returned by
GetLastError(), which would have no relationship to the actual problem,
and might as well be zero.
Until now we assumed that _open_osfhandle() would set _doserrno on
failure. This assumption was very wrong in one obvious case, namely when
the CRT file descriptor table would fill up. In that case errno is set
to EMFILE, but GetLastError() returns zero - which makes sense because
it's not a win32 error but rather a CRT problem.
Before, when the user passed an invalid paramter to uv_fs_open, libuv
would detect this and call SET_REQ_RESULT to set the result value to -1.
SET_REQ_RESULT then stored whatever error code was returned by
GetLastError(), which would have no relationship to the actual problem,
and might as well be zero.
