vm_core.h: ruby_error_stream_closed

	* vm_core.h (ruby_special_exceptions): renamed
	  ruby_error_closed_stream as ruby_error_stream_closed, like the
	  message.
	speed up IO#close with many threads

	Today, it increases IO#close performance with many threads:

	  Execution time (sec)
	  name            trunk   after
	  vm_thread_close 4.276   3.018

	  Speedup ratio: compare with the result of `trunk' (greater is better)
	  name            after
	  vm_thread_close 1.417

	This speedup comes because rb_notify_fd_close only scans threads
	inside rb_thread_io_blocking_region, not all threads in the VM.

	In the future, this type data structure may allow us to notify
	waiters of multiple FDs on a single thread (when using
	Fibers).

	* thread.c (struct waiting_fd): declare
	  (rb_thread_io_blocking_region): use on-stack list waiter
	  (rb_notify_fd_close): walk vm->waiting_fds instead
	  (call_without_gvl): remove old field setting
	  (th_init): ditto
	* vm_core.h (typedef struct rb_vm_struct): add waiting_fds list
	* (typedef struct rb_thread_struct): remove waiting_fd field
	  (rb_vm_living_threads_init): initialize waiting_fds list

	I am now kicking myself for not thinking about this 3 years ago
	when I introduced ccan/list in [Feature #9632] to optimize this
	same function :<
	IO#close: do not enqueue redundant interrupts (take #2)

	Enqueuing multiple errors for one event causes spurious errors
	down the line, as reported by Nikolay Vashchenko in
	https://bugs.ruby-lang.org/issues/13632

	This should fix bad interactions with test_race_gets_and_close
	in test/ruby/test_io.rb since we ensure rb_notify_fd_close
	continues returning the busy flag after enqueuing the interrupt.

	Backporting changes to 2.4 and earlier releases will be more
	challenging...

	* thread.c (rb_notify_fd_close): do not enqueue multiple interrupts
	  [ruby-core:81581] [Bug #13632]
	* test/ruby/test_io.rb (test_single_exception_on_close):
	  new test based on script from Nikolay

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_4@59286 b2dd03c8-39d4-4d8f-98ff-823fe69b080e