[#81492] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — normalperson@...
Issue #13618 has been reported by normalperson (Eric Wong).
12 messages
2017/06/01
[#88695] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/08/27
> https://bugs.ruby-lang.org/issues/13618
[#81569] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
3 messages
2017/06/04
[#81581] [Ruby trunk Bug#13632] Not processable interrupt queue for a thread after it's notified that FD is closed in some other thread. — sir.nickolas@...
Issue #13632 has been reported by nvashchenko (Nikolay Vashchenko).
4 messages
2017/06/05
[#81590] Re: [ruby-cvs:66197] ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures. — Eric Wong <normalperson@...>
ko1@ruby-lang.org wrote:
5 messages
2017/06/06
[#81591] Re: [ruby-cvs:66197] ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures.
— Eric Wong <normalperson@...>
2017/06/06
Eric Wong <normalperson@yhbt.net> wrote:
[#81596] Re: [ruby-cvs:66203] Re: Re: ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures.
— Eric Wong <normalperson@...>
2017/06/06
Eric Wong <normalperson@yhbt.net> wrote:
[#81825] [Ruby trunk Feature#13697] [PATCH]: futex based thread primitives — normalperson@...
Issue #13697 has been reported by normalperson (Eric Wong).
3 messages
2017/06/29
[ruby-core:81674] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
From:
Eric Wong <normalperson@...>
Date:
2017-06-14 02:49:31 UTC
List:
ruby-core #81674
samuel@oriontransfer.org wrote:
> Does Ruby `File.read` and `File.stat` (and others) release the GVL? Otherwise, the performance benefit of multiple threads in this specific case is irrelevant. While I agree with you when writing high performance servers in C/C++, it might not be directly relevant to Ruby as it currently stands.
File.read does. File.stat does not, at the moment. I tried
it a while back but the GVL is expensive to release for hot
cache situations(*).
File.open, IO.copy_stream, IO#write, IO#read, readpartial, sysread,
syswrite all release GVL, too.
In particular, IO.copy_stream is great for large, parallel
transfers to/from high-latency storage.
(*) the cost of GVL for quick ops is a big reason I want to get rid of it
But yeah, maybe the small regression from releasing GVL is
acceptable for now with File.stat. It's better than getting
stufk on NFS or slow disks.
File.rename, File.unlink, most Dir methods all have the same
problem with slow storage, too. We already pay the price
for small regressions when releasing GVL in current cases,
so maybe those can be GVL release points.
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>