Eric Wong wrote:
> Fwiw, I can still reproduce the failures with low timeouts:
> 
> ```
> diff --git a/thread_pthread.c b/thread_pthread.c
> index 2fd60ddd4a..e8da3ee9c2 100644
> --- a/thread_pthread.c
> +++ b/thread_pthread.c
> @@ -187,7 +187,7 @@ do_gvl_timer(rb_vm_t *vm, rb_thread_t *th)
>  
>      if (vm->gvl.timer_err == ETIMEDOUT) {
>          ts.tv_sec = 0;
> -        ts.tv_nsec = TIME_QUANTUM_NSEC;
> +        ts.tv_nsec = 1;
>          ts = native_cond_timeout(&nd->cond.gvlq, ts);
>      }
>      vm->gvl.timer = th;
> ```
> 
> So there's definitely more to investigate until I'm satisified
> with the reliability of this (but I'm too tired, now).

I think the only way to work reliably is to disable interrupt
checking when attempting to lock a mutex in ensure:

  https://80x24.org/spew/20180819193954.13807-1-e / 80x24.org/raw

We can rely on deadlock checking to prevent problems; but it
could still affect user-experience if Ctrl-C takes a while
*shrug*

Currently testing, will take a while.

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