[ruby-core:81306] [Ruby trunk Feature#13575][Closed] [PATCH] speed up IO#close with many threads

From: normalperson@...
Date: 2017-05-20 09:48:29 UTC
List: ruby-core #81306
Issue #13575 has been updated by normalperson (Eric Wong).

Status changed from Open to Closed

r58812


----------------------------------------
Feature #13575: [PATCH] speed up IO#close with many threads
https://bugs.ruby-lang.org/issues/13575#change-64983

* Author: normalperson (Eric Wong)
* Status: Closed
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
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 :<


---Files--------------------------------
0001-speed-up-IO-close-with-many-threads.patch (4.66 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next