[#80531] Re: [ruby-cvs:65407] normal:r58236 (trunk): thread.c: comments on M:N threading [ci skip] — Eric Wong <normalperson@...>
SASADA Koichi <ko1@ruby-lang.org> wrote:
On 2017/04/02 11:35, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
Eric Wong <normalperson@yhbt.net> wrote:
On 2017/05/08 9:33, Eric Wong wrote:
On 2017/05/08 10:53, SASADA Koichi wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2017/05/08 12:01, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2017/05/08 15:36, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2017/05/09 12:38, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2017/05/09 14:12, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2017/05/09 15:23, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
Thank you.
[#80763] [Ruby trunk Feature#13434] better method definition in C API — naruse@...
Issue #13434 has been updated by naruse (Yui NARUSE).
[#80844] [Ruby trunk Bug#13503] Improve performance of some Time & Rational methods — watson1978@...
Issue #13503 has been updated by watson1978 (Shizuo Fujita).
[#80892] [Ruby trunk Misc#13514] [PATCH] thread_pthread.c (native_sleep): preserve old unblock function — ko1@...
Issue #13514 has been updated by ko1 (Koichi Sasada).
ko1@atdot.net wrote:
On 2017/04/27 8:58, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
Eric Wong <normalperson@yhbt.net> wrote:
[ruby-core:80775] Re: [Ruby trunk Feature#13434] better method definition in C API
naruse@airemix.jp wrote:
> Issue #13434 has been updated by naruse (Yui NARUSE).
>
>
> I agree with the concept.
>
> From r55102, rb_scan_args is statically resolved by C compilers on some environment, rb_get_kwargs is still inefficient.
> To allow C compilers statically resolve them, Ruby method in C should be defined in more machine friendly way.
Cool, I forgot about that rb_scan_args optimization. Maybe we
can use similar optimization for defining methods, too,
to speed up VM startup.
> I thought the new API should use C struct (write rb_method_info by hand?).
I think the new API should resemble pure Ruby method definition
for ease-of-learning. But, we will need a new way to mark
unused/readonly...
> Anyway we should list up the requirement of the new API, for example
> * readonly/unused flag for arguments.
> * whether the caller requires return single value, multiple value (like Perl's wantarray), or not.
Agreed on all of these.
For wantarray, I think we can support returning klass==0
(hidden) array from C methods. We then teach the VM to treat
klass==0 Array return values as a special case: the VM will set
klass=rb_cArray lazily if capturing the array is required.
In other words, this example:
static VALUE cfunc(VALUE self)
{
VALUE ret = rb_ary_tmp_new(3);
rb_ary_push(ret, INT2FIX(1));
rb_ary_push(ret, INT2FIX(2));
rb_ary_push(ret, INT2FIX(3));
return ret; /* klass == 0 */
}
Example 1, return value is discarded immediately:
a, b, c = cfunc
In the above case, the VM calls:
rb_ary_clear(ret);
rb_gc_force_recycle(ret)
after assigning a, b, c since the temporary array is no longer
used.
Example 2, return value is preserved:
a, b, c = ary = cfunc
In the above case, the VM calls:
rb_obj_reveal(ret, rb_cArray)
since it is assigned to `ary`.
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>