unix: move uv__connect() to tcp.c
unix: deduplicate socket creation code in tcp.c

Incidentally fixes a rather obscure bug where uv_tcp_connect() reconnected
and leaked a file descriptor when the handle was already busy connecting,
handle->fd was zero (unlikely) and uv_tcp_connect() got called again.
unix: fix EINPROGRESS busy loop

Don't make the event loop spin when connect() returns EINPROGRESS.

Test case:

  #include "uv.h"

  static void connect_cb(uv_connect_t* req, int status) {
    // ...
  }

  int main() {
    uv_tcp_t handle;
    uv_connect_t req;
    struct sockaddr_in addr;
    addr = uv_ip4_addr("8.8.8.8", 1234); // unreachable
    uv_tcp_init(uv_default_loop(), &handle);
    uv_tcp_connect(&req, (uv_stream_t*)&handle, addr, connect_cb);
    uv_run(uv_default_loop()); // busy loops until connection times out
    return 0;
  }

After EINPROGRESS, there are zero active handles and one active request. That
in turn makes uv__poll_timeout() believe that it should merely poll, not block,
in epoll() / kqueue() / port_getn().

Sidestep that by artificially starting the handle on connect() and stopping it
again once the TCP handshake completes / is rejected / times out.

It's a slightly hacky approach because I don't want to change the ABI of the
stable branch. I'll address it properly in the master branch.
test: add 'unexpected read' tcp test

Regression test that verifies that the event loop doesn't busy loop when
the server sends a message and the client isn't reading.
unix: fix busy loop on unexpected tcp message

Don't start reading immediately after connecting. If the server sends a message
and the client hasn't called uv_read_start() yet, the event loop will busy loop
because the pending message keeps waking it up.
unix: fix 'zero handles, one request' busy loop

Fixes #484.
unix: revert 0971598, obsoleted by 889ab21
unix: rename linux/core.c to linux/linux-core.c

This is a back-port of commit e1320757 from the master branch.

Newer versions of gyp do not support files with the same basenames (example:
core.c and linux/core.c).

The nominal reason is consistency across build systems. Apparently, msbuild
doesn't support it either.

Somewhere, someplace, baby Jesus cries sad little tears...

Fixes #464.
test: allow 80 ms intervals in hrtime test

The hrtimer functionality on my FreeBSD 9 system is fairly coarse, it's usually
just over the 60 ms that we tested for before this commit.
unix: fix memory corruption in freebsd.c
unix: thread: use mach semaphores on osx
unix: move uv_set_process_title() to proctitle.c

Use hijacking argv array to change process' title. It seems to be working fine
on almost every platform (at least it should not break anything as it's used in
nginx in a similar way).
unix: avoid buffer overflow in proctitle.c

Get/set process title with uv_strlcpy(), not strncpy(). The latter won't
zero-terminate the result if the destination buffer is too small.
unix: fix format string vulnerability in freebsd.c

uv_set_process_title() was susceptible to a format string vulnerability:

  $ node -e 'process.title = Array(42).join("%s")'
  Segmentation fault: 11 (core dumped)

The fix is trivial - call setproctitle("%s", s) instead of setproctitle(s) -
but valgrind complains loudly about reads from and writes to uninitialized
memory in libc. It's not a libuv bug because the test case below triggers the
same warnings:

  #include <stdio.h>
  #include <stdlib.h>
  #include <sys/types.h>
  #include <unistd.h>

  int main(void)
  {
    setproctitle("%s", "test");
    return 0;
  }

That's why this commit replaces setproctitle() with sysctl(KERN_PROC_ARGS).
unix: fix uv_set_process_title()

Use strncpy() to set the process title, it pads the remainder with nul bytes.
Avoids garbage output on systems where `ps aux` prints the entire proctitle
buffer, not just the characters up to the first '\0'.

Fixes joyent/node#3726.
unix: undo changes to uv_set_process_title()

It's making node.js crash when run as root. Backtrace:

  (gdb) bt
  #0  0x00007fff856e3ff9 in __findenv ()
  #1  0x00007fff856e404c in getenv ()
  #2  0x000000010004c850 in loop_init (loop=0x10045a792, flags=8) at ev.c:1707
  #3  0x000000010004cb3b in ev_backend [inlined] () at /Users/tjfontaine/Development/node/deps/uv/src/unix/ev/ev.c:2090
  #4  0x000000010004cb3b in ev_default_loop (flags=1606417108) at ev.c:2092
  #5  0x000000010004e5c6 in uv__loop_init (loop=0x10066e330, default_loop=1) at loop.c:52
  #6  0x0000000100044367 in uv_default_loop () at core.c:196
  #7  0x0000000100004625 in node::Init (argc=1606417456, argv=0x100b0f490) at node.cc:2761
  #8  0x000000010000797d in node::Start (argc=1606417600, argv=0x0) at node.cc:2888
  #9  0x0000000100000ca4 in start ()

This reverts commits:

  b49d6f7 unix: fix uv_set_process_title()
  a9f6f06 unix: fix format string vulnerability in freebsd.c
  a87abc7 unix: avoid buffer overflow in proctitle.c
  dc97d44 unix: move uv_set_process_title() to proctitle.c
unix: fix errno reporting in uv_pipe_connect()

Remember the errno when the socket() syscall fails.
unix: fix uv_pipe_connect() with existing fd

Don't create a new socket descriptor if one has been previously assigned with
uv_pipe_open().
unix: fix format string vulnerability in freebsd.c

uv_set_process_title() was susceptible to a format string vulnerability:

  $ node -e 'process.title = Array(42).join("%s")'
  Segmentation fault: 11 (core dumped)

The fix is trivial - call setproctitle("%s", s) instead of setproctitle(s) -
but valgrind complains loudly about reads from and writes to uninitialized
memory in libc. It's not a libuv bug because the test case below triggers the
same warnings:

  #include <sys/types.h>
  #include <unistd.h>

  int main(void)
  {
    setproctitle("%s", "test");
    return 0;
  }

That's why this commit replaces setproctitle() with sysctl(KERN_PROC_ARGS).

This commit reapplies commit a9f6f06, which got reverted in 69a6afe. The revert
turned out to be unnecessary.
unix: don't abort() when trylock functions return EBUSY

Fixes #500.