SASADA Koichi <ko1 / atdot.net> wrote:
> On 2017/04/27 12:57, Eric Wong wrote:
> > https://80x24.org/spew/20170427034243.22272-1-e / 80x24.org/raw
> 
> Thank you. I understand the idea. My understanding is "Do not rely on
> native cond, but manage sleeping threads by ourselves (manage waiting
> queue)". It sound great.

Thank you for looking at it.  I will open separate ticket once
I am satisfied with it.  All internal tests and rubyspec pass,
but I need to review patrol thread logic, more.

> However, I can't understand well about changing native_sleep(). Before
> native_sleep(), GVL was acquired and UBF is zero. What kind of sequence
> do you think which requires [Misc #13514]?

Again, I am really not sure what requires [Misc #13514],
it does not feel correct to lose existing values...


Note how my Mutex size reduction patch at
<https://80x24.org/spew/20170427034243.22272-1-e / 80x24.org/raw>
still uses set_unblock_function and reset_unblock_function in
rb_mutex_lock around native_sleep.

This is what the original code did with lock_func.

Maybe they are not necessary with native_sleep,
since "make exam" passes, but I am also unsure why the old code
in rb_mutex_lock used reset_unblock_function instead of zeroing
UBF like native_sleep...

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