windows: relay TCP bind errors via ipc

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

windows: relay TCP bind errors via ipc

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 (
https://github.com/joyent/libuv/commit/d1e6be1460f555a1f8a4063d7642696aa7238769
https://github.com/joyent/node/commit/3da36fe00e5d85414031ae812e473f16629d8645
) 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.

show more ...

windows: change GENERIC_ALL to GENERIC_WRITE in fs__create_junction

Fixes #1385

See ReactOS's mklink implementation and
http://stackoverflow.com/a/10508724

build: handle platforms without multiprocessing.synchronize

unix, windows: add uv_fs_mkdtemp

windows: destroy work queue elements when colsing a loop

Destroy the async handle used to notify about work being done, and the
mutex used to protect each loop's work queue.

Clo

windows: destroy work queue elements when colsing a loop

Destroy the async handle used to notify about work being done, and the
mutex used to protect each loop's work queue.

Closes #1375

show more ...

windows: don't use atexit for cleaning up the threadpool

If libuv is loaded as a DLL and is later unloaded deadlocks can happen
when running atexit handlers, so we can't use synchronizat

windows: don't use atexit for cleaning up the threadpool

If libuv is loaded as a DLL and is later unloaded deadlocks can happen
when running atexit handlers, so we can't use synchronization
priomitives or join threads there.

For reference see https://github.com/saghul/pyuv/issues/171

show more ...

doc: update link to pyuv in README

windows: return bind error immediately when implicitly binding

If a TCP handle is bound automatically when calling uv_listen or
uv_connect, there is a remote possibility that it fails, r

windows: return bind error immediately when implicitly binding

If a TCP handle is bound automatically when calling uv_listen or
uv_connect, there is a remote possibility that it fails, return
the error if so.

show more ...

aix: improve AIX compatibility

doc: add logo image to README

img: add logo files

unix: guarantee write queue cb execution order in streams

The problem was that the canceled write callbacks
were being called before the already written callbacks, even
though they w

unix: guarantee write queue cb execution order in streams

The problem was that the canceled write callbacks
were being called before the already written callbacks, even
though they were queued after them.

show more ...

openbsd: avoid requiring privileges for uv_resident_set_memory

doc: clarify the return value of uv_default_loop

unix: remove incorrect assert

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

unix: remove incorrect assert

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.

show more ...

doc: clarify why we don't use SO_REUSEADDR for TCP on Windows

test: fix watcher_cross_stop

It's possible that recv_cb_called is bigger than the number of sockets,
because if all sends succeed the recv callback is called twice: once
with the act

test: fix watcher_cross_stop

It's possible that recv_cb_called is bigger than the number of sockets,
because if all sends succeed the recv callback is called twice: once
with the actual data, and another time with 0.

show more ...

unix: try to write immediately in uv_udp_send

doc: cleanup API documentation in uv.h

windows: map ERROR_INVALID_DRIVE to UV_ENOENT

build: fix build on MinGW32

windows: disable CRT debug handler on MinGW32

We cannot actually use it because the header is not present, so disable
it. On MinGW-w64 it does work though.

windows: count queued bytes even if request completed immediately

The send_queue_size/count needs to maintain its value until right before
the callback is called.

windows: fix compatibility with cygwin pipes

This makes libuv more tolerant to the properties of the pipes
that it can use without any issue. This is necessary because Cygwin
(and he

windows: fix compatibility with cygwin pipes

This makes libuv more tolerant to the properties of the pipes
that it can use without any issue. This is necessary because Cygwin
(and hence Mintty) opens STDIN without FILE_WRITE_ATTRIBUTES.

show more ...

doc: grammar, udp documentation fix up