From: mame@... Date: 2017-05-01T08:41:22+00:00 Subject: [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: