uv_update_time does not overwrite the high 32 bits of uv_loop_t.time.
It merely increments it by one when the low 32 bits have wrapped. That
means that `time` needs to be initialized to zero before
uv_update_time() is called for the first time.
Don't try the pipe2() or socketpair(O_CLOEXEC) syscalls when a previous call to
uv__make_pipe() or uv__make_socketpair() call established that the kernel
doesn't support it. Speeds up pipe and socketpair creation on older kernels.
Variables tagged with __read_mostly are put into a separate ELF section to
improve the cache locality of data that is read often but seldom written to.
kqueue(2) on osx doesn't work (emits EINVAL error) with specific fds
(i.e. /dev/tty, /dev/null, etc). When given such descriptors - start
select(2) watcher thread that will emit io events.
uv_fs_poll_t has an embedded uv_timer_t handle that got closed at a time when
the memory of the encapsulating handle might already have been deallocated.
Solve that by moving the poller's state into a structure that is allocated on
the heap and can be freed independently.
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.
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.
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.
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 (;;);
}
poll() on newer versions of OS X sets POLLHUP|POLLIN whereas older versions
(and other Unices) only set POLLHUP. It was tripping up a check that expected
to read data when POLLIN was set.
While easy to work around, I switched it to a blocking read instead:
it's less code and avoids surprises like the one above altogether.
Fixes#522.
OS X has no public API for fdatasync. And as pointed out in `man fsync(2)`:
For applications that require tighter guarantees about the integrity of
their data, Mac OS X provides the F_FULLFSYNC fcntl. The F_FULLFSYNC
fcntl asks the drive to flush all buffered data to permanent storage.
Applications, such as databases, that require a strict ordering of writes
should use F_FULLFSYNC to ensure that their data is written in the order
they expect. Please see fcntl(2) for more detail.
