[#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:80894] Re: [Ruby trunk Misc#13514] [PATCH] thread_pthread.c (native_sleep): preserve old unblock function
ko1@atdot.net wrote:
> Issue #13514 has been updated by ko1 (Koichi Sasada).
>
>
> Do you expect such situation?
Not right now. I am looking at making changes related to
threading, and I noticed this weirdness.
> (1) run ruby code # acquiring GVL
> (2) run func on without_gvl() # releasing GVL
> (3) run func on with_gvl() # re-acquire GVL
> (4) run func on without_gvl() # releasing GVL <- here
>
> I agree. It has a problem. But we should save UBF at `with_gvl()` function, I assume.
> And checking `thread.c`, it is saved.
Yes, I do not believe there is a problem in current code.
For lack of better explanation, it seems wrong to lose
any existing values.
> What situation do you assume?
I am looking to replace lock_func in thread_sync.c with
native_sleep or similar. This is to reduce Mutex size and
complexity by using a similar method to what I did in r52332
with ccan/list
("variable.c: additional locking around autoload")
It is compatible with current GVL 1:1 threading,
but I would like to support M:N threading, eventually.
Thanks for looking at this.
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>