Hi Ken, On Jun 24 20:19, Ken Brown wrote: > If a timer expires while the timerfd thread is in its inner loop, > check for the thread cancellation event before trying to enter > a_critical_section. It's possible that timerfd_tracker::dtor has > entered its critical section and is trying to cancel the thread. See > http://www.cygwin.org/ml/cygwin/2019-06/msg00096.html. > --- > winsup/cygwin/timerfd.cc | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/winsup/cygwin/timerfd.cc b/winsup/cygwin/timerfd.cc > index 8e4c94e66..e8261ef2e 100644 > --- a/winsup/cygwin/timerfd.cc > +++ b/winsup/cygwin/timerfd.cc > @@ -137,6 +137,11 @@ timerfd_tracker::thread_func () > continue; > } > > + /* Avoid a deadlock if dtor has just entered its critical > + section and is trying to cancel the thread. */ > + if (IsEventSignalled (cancel_evt)) > + goto canceled;
This looks still racy, what if cancel_evt is set just between the IsEventSignalled() and enter_critical_section() calls? Hmm. What if we redefine enter_critical_section() to return three states. It calls WFMO on cancel_evt and _access_mtx, in this order, so that a cancel event is honored. Or maybe introduce another function like enter_critical_section_cancelable() which is only called in this single instance in timerfd_tracker::thread_func? Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer
signature.asc
Description: PGP signature
