[#83096] File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?}) — Nobuyoshi Nakada <nobu@...>
On 2017/10/04 8:47, [email protected] wrote:
5 messages
2017/10/04
[#83100] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Eric Wong <normalperson@...>
2017/10/04
Nobuyoshi Nakada <[email protected]> wrote:
[#83105] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Nobuyoshi Nakada <nobu@...>
2017/10/04
On 2017/10/04 15:55, Eric Wong wrote:
[#83107] Alias Enumerable#include? to Enumerable#includes? — Alberto Almagro <albertoalmagro@...>
Hello,
9 messages
2017/10/04
[#83113] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/05
This has been requested countless times, then rejected each and every time.
[#83129] Re: Alias Enumerable#include? to Enumerable#includes?
— Alberto Almagro <albertoalmagro@...>
2017/10/05
Sorry I didn't found it on the core mail list's archive.
[#83138] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/06
Ruby has not been made of popular votes so far. You have to show us
[#83149] Re: Alias Enumerable#include? to Enumerable#includes?
— Eric Wong <normalperson@...>
2017/10/06
Alberto Almagro <[email protected]> wrote:
[#83200] [Ruby trunk Feature#13996] [PATCH] file.c: apply2files releases GVL — normalperson@...
Issue #13996 has been reported by normalperson (Eric Wong).
4 messages
2017/10/10
[ruby-core:83073] [Ruby trunk Feature#13951] [PATCH] File#rename releases GVL
From:
nobu@...
Date:
2017-10-01 12:43:04 UTC
List:
ruby-core #83073
Issue #13951 has been updated by nobu (Nobuyoshi Nakada).
Description updated
normalperson (Eric Wong) wrote:
> I consider the performance trade off acceptable as cases are avoided.
I agree that it would be small enough.
gcc for x86_64 warns:
```
file.c: In function 'no_gvl_rename':
file.c:2886:12: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
return (void *)rename(ra->src, ra->dst);
^
file.c: In function 'rb_file_s_rename':
file.c:2914:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if ((int)rb_thread_call_without_gvl(no_gvl_rename, &ra,
^
```
----------------------------------------
Feature #13951: [PATCH] File#rename releases GVL
https://bugs.ruby-lang.org/issues/13951#change-67021
* Author: normalperson (Eric Wong)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
rename(2) requires two pathname resolution operations which can
take considerable time on slow filesystems, release the GVL so
operations on other threads may proceed.
On fast, local filesystems, this change results in some slowdown
as shown by the new benchmark. I consider the performance trade
off acceptable as cases are avoided.
```
benchmark results:
minimum results in each 3 measurements.
Execution time (sec)
name trunk built
file_rename 2.648 2.804
Speedup ratio: compare with the result of `trunk' (greater is better)
name built
file_rename 0.944
```
* file.c (no_gvl_rename): new function
(rb_file_s_rename): release GVL for renames
* benchmark/bm_file_rename.rb: new benchmark
I will commit this next week as well as work on releasing GVL for
other operations where slow FS can have pathological slowdown
(unlink, link, symlink, readlink, readdir, mkdir, chmod, ...)
---Files--------------------------------
0001-File-rename-releases-GVL.patch (2.64 KB)
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>