Fixes the following warning:
src\uv-common.c(476): warning C4715:
'uv__getaddrinfo_translate_error' : not all control paths return
a value
The function never returns - the final statement is a call to abort() -
but it seems MSVC's program flow analyzer is too weak to figure that
out.
mingw32 doesn't have the JOB_OBJECT_XXX defines. Provide them ourselves
when they are not already defined.
This is possibly only an issue with older versions of mingw32 because
mingw-w64 2.0 _does_ export the defines.
Change the uv_fs_write() prototype so the 'buf' argument is now
`const void*` rather than `void*`.
The argument is stored in a non-const field in the uv_fs_t but that's
inconsequential because the memory it points to is not touched.
* add a very simple Makefile.mingw that builds libuv.a
* apply a couple of fixes to src/win so it actually builds with mingw
(mostly missing includes)
Fixes#847.
Make it possible for the libuv user to handle out of memory conditions
gracefully. When alloc_cb() returns a buffer with len==0, call the read
or recv callback with nread=UV_ENOBUFS. It's up to the user to stop or
close the handle.
Fixes#752.
Before this commit, uv_fs_chown() and uv_fs_fchown() took the uid and
gid as signed integers which is wrong because uid_t and gid_t are
unsigned on most all platforms and IDs that don't fit in a signed
integer do exist.
This is not an ABI change because the size of the uid and gid arguments
do not change, only their sign.
On Windows, uv_uid_t and uv_gid_t are typedef'd as unsigned char for
reasons that are unclear. It doesn't matter: they get cast to ints when
used as function arguments. The arguments themselves are unused.
Partial fix for joyent/node#5890.
This commit changes the libuv API to return error codes directly rather
than storing them in a loop-global field.
A code snippet like this one:
if (uv_foo(loop) < 0) {
uv_err_t err = uv_last_error(loop);
fprintf(stderr, "%s\n", uv_strerror(err));
}
Should be rewritten like this:
int err = uv_foo(loop);
if (err < 0)
fprintf(stderr, "%s\n", uv_strerror(err));
The rationale for this change is that it should make creating bindings
for other languages a lot easier: dealing with struct return values is
painful with most FFIs and often downright buggy.
Switch to the build tool everyone loves to hate. The Makefile has
served us well over the years but it's been acquiring more and more
features that autotools gives us for free, like easy static+shared
library building, sane install targets, and so on.
This commit drops MinGW support. If there is demand for it, we'll
re-add it.
Changes since version 0.11.4:
* build: remove CSTDFLAG, use only CFLAGS (Ben Noordhuis)
* unix: support for android builds (Linus Mårtensson)
* unix: avoid extra read, short-circuit on POLLHUP (Ben Noordhuis)
* uv: support android libuv standalone build (Linus Mårtensson)
* src: make queue.h c++ compatible (Ben Noordhuis)
* unix: s/ngx-queue.h/queue.h/ in checksparse.sh (Ben Noordhuis)
* unix: unconditionally stop handle on close (Ben Noordhuis)
* freebsd: don't enable dtrace if it's not available (Brian White)
* build: make HAVE_DTRACE=0 should disable dtrace (Timothy J. Fontaine)
* unix: remove overzealous assert (Ben Noordhuis)
* unix: remove unused function uv_fatal_error() (Ben Noordhuis)
* unix, windows: clean up uv_thread_create() (Ben Noordhuis)
* queue: fix pointer truncation on LLP64 platforms (Bert Belder)
* build: set OS=="android" for android builds (Linus Mårtensson)
* windows: don't use uppercase in include filename (Ben Noordhuis)
* stream: add an API to make streams do blocking writes (Henry Rawas)
* windows: use WSAGetLastError(), not errno (Ben Noordhuis)
This patch adds the `uv_stream_set_blocking` API which makes all
uv_write calls to that stream blocking. It currently only works for
pipes, on windows.
This fixes an issue where uv_spawn would not try to run a reparse point,
and continue to scan the PATH instead. Effectively, it was impossible to
spawn a symlinked binary. This commit fixes that.
Also see #748
QUEUE_DATA used to cast a pointer to long and back to pointer. This can
corrupt pointers on systems where the long type isn't large enough to
store pointer, like Windows x64. This commit fixes that.
Fixes#835
Changes since version 0.10.10:
* unix: unconditionally stop handle on close (Ben Noordhuis)
* freebsd: don't enable dtrace if it's not available (Brian White)
* build: make HAVE_DTRACE=0 should disable dtrace (Timothy J. Fontaine)
* unix: remove overzealous assert (Ben Noordhuis)
* unix: clear UV_STREAM_SHUTTING after shutdown() (Ben Noordhuis)
* unix: fix busy loop, write if POLLERR or POLLHUP (Ben Noordhuis)
This fixes a busy loop by working around a quirk with Linux kernels
<= 2.6.32 where an EPIPE or ECONNRESET error on a file descriptor that
is polled for EPOLLOUT but not EPOLLIN gets reported by epoll_wait() as
just EPOLLERR|EPOLLHUP, like this:
epoll_wait(5, {{EPOLLERR|EPOLLHUP, {u32=12, u64=12}}}, 1024, 433) = 1
Before this commit, libuv called uv__read() which attempts to read from
the file descriptor. With newer kernels and on other operating systems
that fails like this:
read(12, "", 65536) = -1 EPIPE (Broken pipe)
Which tells libuv there is a connection error and it should notify the
user of that. On the affected Linux kernels however, the read succeeds
with an EOF:
read(12, "", 65536) = 0
Which is subsequently passed on to the user. In most cases, the user
will close the handle and everything is fine.
Node.js however sometimes keeps the handle open in an attempt to flush
pending write requests. While libuv doesn't officially support this,
unofficially it works...
...except on those older kernels. Because the kernel keeps waking up
the event loop without setting POLLOUT and because the read calls EOF
but don't error, libuv's I/O state machine doesn't progress.
That's why this commit changes uv__stream_io() to also write pending
data. While the read() system call doesn't error, the write() system
call will.
Fixesjoyent/node#5504.
Several node.js users are hitting this assert under what appear to be
mostly benign conditions. In other words, it's unclear whether it's
catching real bugs or just has wrong expectations.
An aborting process is rather disruptive so I'm removing the assert
from the stable branch and relanding it in the master branch.
