[ruby-core:80955] [Ruby trunk Misc#13514] [PATCH] thread_pthread.c (native_sleep): preserve old unblock function

Issue #13514 has been updated by mame (Yusuke Endoh).


normalperson (Eric Wong) wrote:
>  > 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...

Perhaps, I first introduced such a preservation code for rb_mutex_lock at r17435.  But sorry, I cannot remeber the reason.

I remember that, at that time, there was a bug in deadlock detection that produces false positive.  I think I introduced a code to preserve UBF as a symptomatic treatment.

Now, I agree with ko1.  Indeed it looks unnecessary.  If we remove the code and all tests pass, I vote for removal.

----------------------------------------
Misc #13514: [PATCH] thread_pthread.c (native_sleep): preserve old unblock function
https://bugs.ruby-lang.org/issues/13514#change-64621

* Author: normalperson (Eric Wong)
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
Do not blindly clobber UBF if one exists, emulating the
behavior of the set_unblock_function and reset_unblock_function
pair.

I think the native_sleep implementation in thread_win32.c,
can use a similar change; but I do not run non-Free software
so I cannot test.


I'm pretty sure this is correct, and will commit in a few days.
On the other hand, I'm not sure if anybody is affected by this.
If it's OK, somebody should also update thread_win32.c since I'm
not comfortable doing so without being able to test.


---Files--------------------------------
0001-thread_pthread.c-native_sleep-preserve-old-unblock-f.patch (1.21 KB)


-- 
https://bugs.ruby-lang.org/

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