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>