From: Eric Wong Date: 2017-04-27T17:51:38+00:00 Subject: [ruby-core:80911] Re: [Ruby trunk Misc#13514] [PATCH] thread_pthread.c (native_sleep): preserve old unblock function SASADA Koichi 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 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: