[Bug #21860]

If a thread was holding this lock before fork, it will not exist in the
child process. We should re-initialize these locks as we do with the VM
locks when forking.

Co-Authored-By: John Hawthorn <john@hawthorn.email>
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>

	Message not found for revision: 62430c19c9f1ab49429cebe65f30588472648c95

	Fix coverage measurement for negative line numbers

	Fixes [Bug #21220]

	Co-Authored-By: Mike Bourgeous <mike@mikebourgeous.com>
	Co-Authored-By: Jean Boussier <jean.boussier@gmail.com>

If one thread is reading and another closes that socket, the close
blocks waiting for the read to abort cleanly. This ensures that Ruby is
totally done with the file descriptor _BEFORE_ we tell the OS to close
and potentially re-use it.

When the read is correctly terminated, the close should be unblocked.
That currently works if closing is happening on a thread, but if it's
happening on a fiber with a fiber scheduler, it does NOT work.

This patch ensures that if the close happened in a fiber scheduled
thread, that the scheduler is notified that the fiber is unblocked.

[Bug #20723]

	Fix pointer incompatiblity

	Since the subsecond part is discarded, WIDEVAL to VALUE conversion is
	needed.

	Some functions are not used when `THREAD_MODEL=none`

	`rb_thread_sched_destroy` is not used now at all

	Don't clear pending interrupts in the parent process. (#10365)

Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>

	Ensure that exiting thread invokes end-of-life behaviour. (#10039)

Inline RB_VM_SAVE_MACHINE_CONTEXT into BLOCKING_REGION

There's an exhaustive explanation of this in the linked redmine bug, but
the short version is as follows:

blocking_region_begin can spill callee-saved registers to the stack for
its own use. That means they're not saved to ec->machine by the call to
setjmp, since by that point they're already on the stack and new,
different values are in the real registers. ec->machine's end-of-stack
pointer is also bumped to accomodate this, BUT, after
blocking_region_begin returns, that points past the end of the stack!

As far as C is concerned, that's fine; the callee-saved registers are
restored when blocking_region_begin returns. But, if another thread
triggers GC, it is relying on finding references to Ruby objects by
walking the stack region pointed to by ec->machine.

If the C code in exec; subsequently does things that use that stack
memory, then the value will be overwritten and the GC might prematurely
collect something it shouldn't.

[Bug #20493]

Assrsion was `events == RB_WAITFD_IN || events == RB_WAITFD_OUT`
but it should accept `RB_WAITFD_IN | RB_WAITFD_OUT`.