From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ruby-core-bounces@ruby-lang.org>
X-Original-To: poffice@blade.nagaokaut.ac.jp
Delivered-To: poffice@blade.nagaokaut.ac.jp
Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24])
	by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 2EE3F19C0021
	for <poffice@blade.nagaokaut.ac.jp>; Thu, 29 Oct 2015 05:08:35 +0900 (JST)
Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100])
	by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 37E30B5D8C9
	for <poffice@blade.nagaokaut.ac.jp>; Thu, 29 Oct 2015 05:36:34 +0900 (JST)
Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75])
	by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 47CB5952408
	for <poffice@blade.nagaokaut.ac.jp>; Thu, 29 Oct 2015 05:36:33 +0900 (JST)
Received: from [221.186.184.76] (localhost [IPv6:::1])
	by neon.ruby-lang.org (Postfix) with ESMTP id 170F01204C9;
	Thu, 29 Oct 2015 05:36:32 +0900 (JST)
X-Original-To: ruby-core@ruby-lang.org
Delivered-To: ruby-core@ruby-lang.org
Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64])
 by neon.ruby-lang.org (Postfix) with ESMTP id 7754E120442
 for <ruby-core@ruby-lang.org>; Thu, 29 Oct 2015 05:36:27 +0900 (JST)
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
 by dcvr.yhbt.net (Postfix) with ESMTP id EEFA3200EA;
 Wed, 28 Oct 2015 20:36:25 +0000 (UTC)
Date: Wed, 28 Oct 2015 20:36:25 +0000
From: Eric Wong <normalperson@yhbt.net>
To: Ruby developers <ruby-core@ruby-lang.org>
Message-ID: <20151028203625.GA18257@dcvr.yhbt.net>
References: <redmine.issue-11607.20151019214639@ruby-lang.org>
 <redmine.journal-54591.20151027084304.26b972846e0c84af@ruby-lang.org>
 <20151027085407.GA7346@dcvr.yhbt.net>
 <20151028144713.GA57208@TC.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151028144713.GA57208@TC.local>
X-ML-Name: ruby-core
X-Mail-Count: 71254
Subject: [ruby-core:71254] Re: [Ruby trunk - Feature #11607] [PATCH] fiddle:
 release GVL for ffi_call
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>
Errors-To: ruby-core-bounces@ruby-lang.org
Sender: "ruby-core" <ruby-core-bounces@ruby-lang.org>

Aaron Patterson <tenderlove@ruby-lang.org> wrote:
> On Tue, Oct 27, 2015 at 08:54:07AM +0000, Eric Wong wrote:
> > Yes, user must check if the function is MT-safe.  Probably fine
> > for most library functions...
> > 
> > Maybe releasing GVL can be optional, but I would rather avoid
> > exposing implementation detail or new APIs...
> 
> I think it's fine.  Calling a C function from fiddle that requires the
> GVL to be locked seems like an edge case.  Maybe we can make an option
> to maintain keep the GVL locked, and make "unlocking the GVL" default
> behavior.

AFAIK, fiddle does not have many users right now[1], correct?
If Ruby eventually loses the GVL, they could get screwed later on if
they rely on GVL, too.  So any potentially breaking change should be
sooner rather than later.

But maybe we introduce a new API/option now to release GVL now.
If/when Ruby loses the GVL; we implement a GFL (Global Fiddle Lock)
and use GFL as default behavior; while the API/option to release
the GVL releases the GFL instead.

I also have some ideas to hopefully make the current GVL cheaper.

[1] I'm not entirely sure why fiddle was introduced since the 'ffi'
    gem was already prevalent.  Was it to keep compatibility with
    'dl'?  Well, at least I can contribute to fiddle without dealing
    ith a non-Free SaaS.