diff options
author | KJ Tsanaktsidis <ktsanaktsidis@zendesk.com> | 2024-01-22 16:22:14 +1100 |
---|---|---|
committer | KJ Tsanaktsidis <kj@kjtsanaktsidis.id.au> | 2024-01-25 13:10:35 +1100 |
commit | ef276858d9295208add48e27208c69184dc50472 (patch) | |
tree | 78a2e7d4260be4ccf96ed886c26e68e9024ac5e2 | |
parent | 2e18228dff4332ec08a0a53ff658ad0bf7133cc0 (diff) |
Trigger postponed jobs on running_ec if that is available
Currently, any postponed job triggered from a non-ruby thread gets sent
to the main thread, but if the main thread is sleeping it won't be
checking ints. Instead, we should try and interrupt running_ec if that's
possible, and only fall back to the main thread if it's not.
[Bug #20197]
-rw-r--r-- | ractor.c | 16 |
1 files changed, 16 insertions, 0 deletions
@@ -2481,6 +2481,22 @@ rb_ractor_terminate_all(void) rb_execution_context_t * rb_vm_main_ractor_ec(rb_vm_t *vm) { + /* This code needs to carefully work around two bugs: + * - Bug #20016: When M:N threading is enabled, running_ec is NULL if no thread is + * actually currently running (as opposed to without M:N threading, when + * running_ec will still point to the _last_ thread which ran) + * - Bug #20197: If the main thread is sleeping, setting its postponed job + * interrupt flag is pointless; it won't look at the flag until it stops sleeping + * for some reason. It would be better to set the flag on the running ec, which + * will presumably look at it soon. + * + * Solution: use running_ec if it's set, otherwise fall back to the main thread ec. + * This is still susceptible to some rare race conditions (what if the last thread + * to run just entered a long-running sleep?), but seems like the best balance of + * robustness and complexity. + */ + rb_execution_context_t *running_ec = vm->ractor.main_ractor->threads.running_ec; + if (running_ec) { return running_ec; } return vm->ractor.main_thread->ec; } |