Revert "windows: readable tty handles need access to console output"

This is not the way to go.
This reverts commit 1b929bfff5be0c03826e3855cb5e1fd3d6421ac7.

unix: split up uv-unix.h

build: handle bad gcc -dumpversion output

`gcc -dumpversion` usually prints major.minor - but on sunos it prints
major.minor.patch.

unix: remove UV_REQ_BUFSML_SIZE

unix: move platform init out of loop.c

Move platform-specific initialization logic out of loop.c and into the
platform files (freebsd.c, sunos.c, etc).

windows: readable tty handles need access to console output

Readable tty handles need to be able to update the virtual window,
so if uv_tty_t is initialized with a console input fd, addi

windows: readable tty handles need access to console output

Readable tty handles need to be able to update the virtual window,
so if uv_tty_t is initialized with a console input fd, additionally
open the console output.

show more ...

windows: separate uv_tty_t read state from write state

windows: small style fix in uv-win.h

sunos: fix uv_cpu_info() on x86_64

kstat_data_lookup("clock_Mhz") returns a KSTAT_DATA_INT32 on i386 but a
KSTAT_DATA_INT64 on x86_64.

include: update uv_timer doc comments

windows: tweak formatting inside uv-win.h

unix: report exit_status==-1 when execve() fails

Call exit_cb with exit_status==-1 when spawning a new process with uv_spawn()
fails.

linux: improve /proc/cpuinfo parser

Make uv_cpu_info() understand the ARM and MIPS versions of /proc/cpuinfo,
it only knew how to deal with the x86 version

This commit also fixe

linux: improve /proc/cpuinfo parser

Make uv_cpu_info() understand the ARM and MIPS versions of /proc/cpuinfo,
it only knew how to deal with the x86 version

This commit also fixes a buglet where uv_cpu_info() reported the maximum CPU
frequency instead of the actual CPU frequency. That is, before this commit
`out/Debug/run-tests platform_output | grep speed | sort | uniq -c` on my
system always reported:

8 speed: 3400

Now it reports (for example):

2 speed: 3400
6 speed: 1600

In other words, two CPUs are running at full speed while the others have been
scaled back because they're mostly idle.

Fixes #526.

show more ...

linux: remove bogus comment in linux-core.c

windows: move uv_atomic_exchange_set to atomicops-inl.h

windows: fix formatting issue in uv-win.h

windows: use WCHAR consistently

windows: report spawn errors to the exit callback

Formerly spawn errors would be reported as a message printed to the
process' stderr, to match unix behaviour. Unix has now been fixed to

windows: report spawn errors to the exit callback

Formerly spawn errors would be reported as a message printed to the
process' stderr, to match unix behaviour. Unix has now been fixed to
be more sensible, so this hack can now be removed.

This also fixes a race condition that could occur when the user closes
a process handle before the exit callback has been made.

show more ...

test: spawn failures are reported by setting the exit code to -1

windows: use UV_ECANCELED to signal canceled requests

This used to be UV_EINTR, but that's not an appropriate error code in
this situation.

test: fix intermittent failure of tcp_unexpected_read on windows

test: avoid compiler complaints about implicit double-to-int cast

windows: un-break the build

unix: fix SIGCHLD race in process.c

Start the SIGCHLD signal watcher before calling fork(). There was a very subtle
race where a child process could quit (and generate a SIGCHILD) before

unix: fix SIGCHLD race in process.c

Start the SIGCHLD signal watcher before calling fork(). There was a very subtle
race where a child process could quit (and generate a SIGCHILD) before the
signal handler was installed.

To reproduce, call uv_spawn() repeatedly with the below x86_64 program:

// compile with `gcc -O2 -nostdlib`
void _start(void)
{
// syscall(SYS_exit, 0)
__asm__ __volatile__ (
"xorq %rdi, %rdi;"
"xorq %rax, %rax;"
"mov $0x3c, %al;"
"syscall;"
);
for (;;);
}

show more ...

Merge branch 'v0.8'