Take advantage of Ruby 3 scheduler.

[ioquatix]

Description

Take direct advantage of the Ruby 3 scheduler interface. While we will try to maintain compatibility as much as possible, there might be some internal scheduler changes which impact the concurrency model (order of operations).

Types of Changes

• New feature.
• Breaking change.
• Performance improvement.

[ioquatix]

Okay, interesting, macOS is passing, Linux is failing.

rspec ./spec/async/scheduler_spec.rb:126 is particularly racey.

[ioquatix]

Async Scheduler thread tests:

-- C level backtrace information -------------------------------------------
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(rb_print_backtrace+0x11) [0x7f0a11fdd08a] vm_dump.c:759
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(rb_vm_bugreport) vm_dump.c:1041
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(rb_bug_for_fatal_signal+0xf4) [0x7f0a11de2d14] error.c:800
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(sigbus+0x4d) [0x7f0a11f324cd] signal.c:946
/lib/x86_64-linux-gnu/libc.so.6(0x7f0a11b54210) [0x7f0a11b54210]
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(RBASIC_CLASS+0x0) [0x7f0a11fcfbd8] ./include/ruby/internal/globals.h:128
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(gccct_method_search) vm_eval.c:422
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(rb_funcallv_scope) vm_eval.c:1013
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(rb_funcallv) vm_eval.c:1039
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(rb_fiber_scheduler_unblock+0x3e) [0x7f0a11f31f1e] scheduler.c:162
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(rb_threadptr_join_list_wakeup+0x2a) [0x7f0a11f7eb5a] thread.c:548
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(thread_start_func_2) thread.c:893
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(register_cached_thread_and_wait+0x0) [0x7f0a11f7f2a2] thread_pthread.c:1033
/home/runner/.rubies/ruby-head/lib/libruby.so.3.1(thread_start_func_1) thread_pthread.c:1040
/lib/x86_64-linux-gnu/libpthread.so.0(start_thread+0xd9) [0x7f0a11ad8609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f0a11c30293]

Seems like rb_fiber_scheduler_unblock is racing with something.

[ioquatix]

This failure only occurs with EPoll on Linux:

[ioquatix]

Okay, at least part of this was a bug due to the GVL releasing code being backwards in the EPoll backend of event: socketry/io-event@181c7a0

[ioquatix]

I found an interesting problem today. In async-pool Semaphore#acquire enter and exit can be context switching point. Because of this, we need to be careful to release resource after acquiring it if we fail. socketry/async-pool@8c6ef4d

In addition, I considered that some parts of async-pool can invoke non-blocking interfaces, e.g. any time we call a method on the supplied class we should be cautious that it can fail with an exception... so we need to probably improve the robustness of the implementation.