[ruby-core:89900] Thread::Light patch against r65832

[Eric Wong <normalperson@yhbt.net>]

> https://bugs.ruby-lang.org/issues/13618

Updated pull request against r65832 with new name: "Thread::Light"

The following changes since commit 8d9a9aab67d6d517995532737a37379c20dc7f76:

  thread_pthread.c (rb_reserved_fd_p): false-positive on negative FD (2018-11-20
 07:27:28 +0000)

are available in the Git repository at:

  https://80x24.org/ruby.git thread-light-r65832

for you to fetch changes up to d03da60f2ef9cf176744168bf2c12b7ab948879c:

  Thread::Light: green threads implemented using fibers (2018-11-20 08:20:48 +00
00)

----------------------------------------------------------------
Eric Wong (2):
      unify sync_waiter, waitpid_state, waiting_fd w/ rb_sched_waiter
      Thread::Light: green threads implemented using fibers

2-patch series (squashed history because there were many names for
this feature (auto-fiber/Thriber/Threadlet/Thread::Coro) and now finally
Thread::Light:

https://80x24.org/spew/20181120083413.43523-2-e@80x24.org/raw
https://80x24.org/spew/20181120083413.43523-3-e@80x24.org/raw

This adds following scheduling points:

C-API scheduling points:

* rb_wait_for_single_fd
* rb_thread_fd_select
* rb_waitpid (SIGCHLD platforms only)

These three functions are used by many Ruby methods, which
all now become scheduling points.

additional Ruby API scheduling points:

* Kernel#sleep
* Thread.pass
* IO.copy_stream
* {Queue,SizedQueue}#{push,pop}

FIXME: the "select"-based implementation still has some missed
events problems.  Fortunately, relevant production systems
use kqueue or epoll which have no known problems at the moment
(tested FreeBSD 11.2 and Linux 4.19.2)

Thread::Light local storage is implemented (#[], #[]=, #fetch, #key?,
and #keys) just like normal Fibers.

Thread::Light#stop? and Thread::Light#status are analogous to
their regular Thread methods.

Thread::Light#run and Thread::Light#wakeup are supported for
waking up from Kernel#sleep.

Mutex and ConditionVariable are NOT scheduling points for
Thread::Light switching; however they may process signal
handling and handle I/O dispatch for other native threads.


Thread::Light.list does not exist, yet (needed?).

I don't know what to do about Thread#raise/Thread#kill...