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 :<

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

1 files changed, 2 insertions, 2 deletions

diff --git a/vm_core.h b/vm_core.h
index 35b1748218..022243fb1d 100644
--- a/vm_core.h
+++ b/vm_core.h
@@ -490,6 +490,7 @@ typedef struct rb_vm_struct {
     struct rb_thread_struct *main_thread;
     struct rb_thread_struct *running_thread;
 
+    struct list_head waiting_fds; /* <=> struct waiting_fd */
     struct list_head living_threads;
     size_t living_thread_num;
     VALUE thgroup_default;
@@ -716,8 +717,6 @@ typedef struct rb_thread_struct {
     /* passing state */
     int state;
 
-    int waiting_fd;
-
     /* for rb_iterate */
     VALUE passed_block_handler;
 
@@ -1442,6 +1441,7 @@ void rb_thread_wakeup_timer_thread(void);
 static inline void
 rb_vm_living_threads_init(rb_vm_t *vm)
 {
+    list_head_init(&vm->waiting_fds);
     list_head_init(&vm->living_threads);
     vm->living_thread_num = 0;
 }