From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ruby-core-bounces@ruby-lang.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS4713 221.184.0.0/13
X-Spam-Status: No, score=-3.1 required=3.0 tests=AWL,BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,SPF_PASS,T_RP_MATCHES_RCVD
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0
Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75])
	by dcvr.yhbt.net (Postfix) with ESMTP id 429FF1FA7B
	for <normalperson@yhbt.net>; Wed, 14 Jun 2017 02:49:40 +0000 (UTC)
Received: from neon.ruby-lang.org (localhost [IPv6:::1])
	by neon.ruby-lang.org (Postfix) with ESMTP id 46F601207B1;
	Wed, 14 Jun 2017 11:49:38 +0900 (JST)
Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64])
 by neon.ruby-lang.org (Postfix) with ESMTPS id AF6FA120766
 for <ruby-core@ruby-lang.org>; Wed, 14 Jun 2017 11:49:33 +0900 (JST)
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
 by dcvr.yhbt.net (Postfix) with ESMTP id 08F1C1FA7B;
 Wed, 14 Jun 2017 02:49:32 +0000 (UTC)
Date: Wed, 14 Jun 2017 02:49:31 +0000
From: Eric Wong <normalperson@yhbt.net>
To: ruby-core@ruby-lang.org
Message-ID: <20170614024931.GA14262@untitled>
References: <redmine.issue-13618.20170601001407@ruby-lang.org>
 <redmine.journal-65363.20170614021338.0a19ead724c06abf@ruby-lang.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <redmine.journal-65363.20170614021338.0a19ead724c06abf@ruby-lang.org>
X-ML-Name: ruby-core
X-Mail-Count: 81674
Subject: [ruby-core:81674] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber
 schedule for rb_wait_for_single_fd and rb_waitpid
X-BeenThere: ruby-core@ruby-lang.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Ruby developers <ruby-core@ruby-lang.org>
List-Id: Ruby developers <ruby-core.ruby-lang.org>
List-Unsubscribe: <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>, 
 <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
List-Post: <mailto:ruby-core@ruby-lang.org>
List-Help: <mailto:ruby-core-request@ruby-lang.org?subject=help>
List-Subscribe: <http://lists.ruby-lang.org/cgi-bin/mailman/listinfo/ruby-core>, 
 <mailto:ruby-core-request@ruby-lang.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ruby-core-bounces@ruby-lang.org
Sender: "ruby-core" <ruby-core-bounces@ruby-lang.org>

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.