From: Eric Wong Date: 2017-08-28T23:51:21+00:00 Subject: [ruby-core:82495] Re: [Ruby trunk Bug#13794] Infinite loop of sched_yield charlie@atech.media wrote: > Eric Wong wrote: > > How about checking owner_process before incrementing? > > I'm afraid this fix doesn't quite match up in my mind. To > clarify, I am suggesting that timer_thread_pipe.writing is > being incremented in the parent process before the fork > occurs. This would still occur because the PID would match at > that point. I am now more sure that checking .owner_process before incrementing is sufficient. We zero .owner_process before looping on the .writing check in native_stop_timer_thread, so if sighandler fires after the .writing check loop in the parent; it could be carried over to the child. Merely checking .owner_process as in my original patch is enough to stop a non-zero .writing value from being carried over to a child. A stronger version which zeroes .writing when re-initializing the timer thread pipe would be: https://80x24.org/spew/20170828232657.GA22848@dcvr/raw However, I think zero-ing .writing is unnecessary, so I stand by my original patch: https://80x24.org/spew/20170809232533.14932-1-e@80x24.org/raw Perhaps the following to ensure (.writing == 0) in rb_thread_create_timer_thread will be useful, at least: https://80x24.org/spew/20170828234743.GA27737@dcvr/raw Unsubscribe: