sleep: measure the remaining time against a clock, not the kernel's remainder

[cyclistmass]

(sleep n) returns late while another thread allocates. On a machine that
collects often enough I have found no bound for the overrun. This is issue #639.

The mechanism

%nanosleep calls #_nanosleep and, on EINTR, sleeps again for the remaining
time the kernel wrote back. Each GC suspends the sleeping thread with a signal,
and suspend_resume_handler blocks inside that handler until the collection
finishes. The kernel computes the remainder before it runs the handler, so the
time the thread spends blocked there is never subtracted. Every world stop adds
its own duration to the sleep, and the error grows with the collection rate.

The fix

Compute the deadline once from a clock the Lisp reads itself. On each EINTR,
sleep for the difference between that deadline and now. The kernel write-back is
never read, so #_nanosleep now gets a NULL rem pointer.

The clock is CLOCK_MONOTONIC through #_clock_gettime where the target has it.
lib/time.lisp already reads that clock the same way for
current-time-in-nanoseconds. On Darwin the deadline comes from gettimeofday,
a kernel import that needs no interface database entry.

I considered clock_nanosleep with TIMER_ABSTIME and did not use it. Darwin
does not have it, so it would need a second loop with a different error
convention for one target. This form is one loop for every target.

The Darwin check goes with the code it guarded. That check read a remainder the
kernel computes as negative and then widens to 64 bits, and nothing reads that
value now.

Cost: one clock_gettime per %nanosleep call, and one more per interruption.
process-wait polls through %nanosleep once per tick, so this is noise there.

Red then green

target	build	a 10 s sleep took	ratio	exit
linuxx8664	host image from before this change	31.8 s	3.2	42
linuxx8664	same pin, same box, with the change	10.0 s	1.0	0
linuxarm64	the series without this change	178.4 s	17.8	42
linuxarm64	same sha, same box, with the change	10.0 s	1.0	0

The control that makes the red mean something is the allocation rate, and it
is flat. On the arm64 pair it is 38,978 allocations per second red against
38,515 green. The red half allocated 18 times more because it ran 18 times
longer, not because the machine changed. Both boxes are burstable 2 vCPU
instances, and a throttled box reproduces this more weakly rather than more
strongly, so these numbers are floors.

What I measured, and what I did not

The two linuxx8664 halves come from 6526e21c. I re-measured the linuxarm64 red
at 27073918, and that pair differs in exactly one file, the boot image: same
kernel binary, same 86 fasls, same image inputs, and the probe reports
%nanosleep-clock absent from the red image and present in the green one.

I have not measured this on Darwin or on Windows. %nanosleep is defined only
for non-Windows targets, and every one of them shares this body, so the change
is not per-port. Windows does not use this function.

The reproducer is extended-tests/threads/sleep-vs-alloc.lisp in
Clozure/ccl-tests#10. It must use the value it allocates, or the compiler removes
the allocation and the sleep returns on time.

[xrme]

It looks like this is a duplicate of #642. Is there some difference I should note?

[cyclistmass]

No difference. The two diffs were byte-identical, 72 lines each. I opened this
as a new branch instead of updating #642, which left two pull requests open for
one fix.

That was our tooling. Our duplicate check compares message bodies inside a
24 hour window and never looked at titles, so two pull requests 43 hours apart
with the same title went straight past it. It now asks GitHub what is already
open under our name before it opens anything.

Keep #642. Your review is there, and I am rebasing it onto get-internal-real-time
as you asked.

Closing this one. Sorry for the round trip.