From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 7835519E0026 for ; Mon, 28 Dec 2015 09:40:13 +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 BEBD3B5D872 for ; Mon, 28 Dec 2015 10:12:47 +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 1505918CC7B9 for ; Mon, 28 Dec 2015 10:12:47 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id A09A912059F; Mon, 28 Dec 2015 10:12:46 +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 E7E7512055E for ; Mon, 28 Dec 2015 10:12:42 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 57B511FF20; Mon, 28 Dec 2015 01:12:42 +0000 (UTC) Date: Mon, 28 Dec 2015 01:12:42 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20151228011242.GA22699@dcvr.yhbt.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 72532 Subject: [ruby-core:72532] Re: [Ruby trunk - Feature #11339] [PATCH] io.c: avoid kwarg parsing in C API X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" headius@headius.com wrote: > Eric Wong wrote: > > Using globals or TLS would introduce subtle reentrancy problems > > when calls are nested. I don't want to create more C-APIs > > we need to support long-term, either. > The global would only be used between the runtime making a call with > keyword arguments and the consumption of those arguments for variable > initialization in a C method. There's no nesting of calls, and once > the C method has consumed the values in the global (i.e. immediately > before doing anything else), it is not touched until the next call > with keywords from Ruby to C. The current rb_get_kwargs() calls may be delayed until the keyword is actually needed (to avoid unnecessary hash lookups). Anyways, if somebody can design a good API for internal use, we can use it. Current rb_get_kwargs() and even rb_scan_args() are inefficient and even error-prone: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/68507 > > Fwiw, I like the Rubinius philosophy of using Ruby as much as > > possible a lot and tried to contribute there back in the day. > > Yes, except that this doesn't buy anything because 99% of the logic of > these methods still lives within C code. If you were also moving the > body of these nonblock methods into Ruby, I'd see some value. You've > removed a couple lines of C and added a couple lines of Ruby. And now > there's going to be an extra method in stack traces and an extra Ruby > frame allocated for every call. It's still a work-in-progress, obviously; but the current state already speeds things up for `exception: false' users. Implementation details will change, of course; but we need freedom to change them by having a smaller public C API.