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.

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>