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.
Disable the fs_event_close_in_callback test on DragonFlyBSD, like we do on the
other BSDs.
The test doesn't work with kqueue-based file notifications, the event is
generated before the file is watched. Maybe we should remove it altogether.
Harmonize with stream.c and tcp.c: when a handle is closed that has pending
writes queued up, run the callbacks with loop->err.code set to UV_ECANCELED,
not UV_EINTR.
Pipe accept benchmarks have never been implemented, remove the code path.
Said code path also contained a bug: it tried to bind to the same pipe that is
bound to a few lines down.
Don't keep writing until the write queue fills up. On fast systems (mine), that
never happens - the data is sent out as fast as the benchmark generates it.
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.
UV_EPIPE is not an error per se, it simply indicates that the other end of the
connection - i.e. the test case - has gone away.
Pro-actively ignore UV_ECANCELED errors. They're not actually emitted right now
because there's only ever one pending write but let's be forward compatible.
Fixes the following valgrind warning:
==29019== Syscall param writev(vector[...]) points to uninitialised byte(s)
==29019== at 0x584270B: writev (writev.c:51)
==29019== by 0x449BB2: uv__write (stream.c:733)
==29019== by 0x44AE91: uv_write2 (stream.c:1159)
==29019== by 0x44AF25: uv_write (stream.c:1180)
==29019== by 0x42CCAA: connect_cb (test-tcp-writealot.c:129)
==29019== by 0x44AC05: uv__stream_connect (stream.c:1097)
==29019== by 0x44AA25: uv__stream_io (stream.c:1050)
==29019== by 0x437430: uv__io_rw (core.c:539)
==29019== by 0x43C3D9: ev_invoke_pending (ev.c:2145)
==29019== by 0x436EC5: uv__poll (core.c:260)
==29019== by 0x436F0F: uv__run (core.c:269)
==29019== by 0x436F6E: uv_run (core.c:277)
==29019== Address 0x5f15040 is 0 bytes inside a block of size 94,371,840 alloc'd
==29019== at 0x4C2C5EF: malloc (vg_replace_malloc.c:270)
==29019== by 0x42CDED: run_test_tcp_writealot (test-tcp-writealot.c:148)
==29019== by 0x406551: run_test_part (runner.c:302)
==29019== by 0x405384: main (run-tests.c:57)
uv_fs_stat and uv_fs_lstat removed the trailing backslash (if any) from the path
in order to please a test case that was written for Windows. Remove the
compatibility hack and fix the test.
