[Fiber Scheduler] Support timeouts

[rsamoilov]

Description

Currently, Rage's fiber scheduler doesn't support manual timeouts. The reference implementation is both slow and consumes too much memory, and thus, it has been commented out.

Instead, the new implementation should work in two steps:

1. The timeout_after method stores the information about the timeout in a hash, calls the block and removes the info from the hash.
2. A separate worker monitors the hash at specific intervals and raises exceptions in timed out fibers.

Tips

• Check Timeout API docs and Fiber::Scheduler#timeout_after docs.
• The two-step process suggested here is used quite ofter in Rage - example 1, example 2.
• Check the architecture doc that shows how Rage's core components interact with each other and outlines the design principles.
• Feel free to ask any questions or request help in the comments below!

[rfronczyk]

Hey @rsamoilov 👋
I took a stab at this and followed the approach you outlined.
First, I implemented a background cleanup fiber that runs on a fixed schedule (every 50ms) and expires timed-out fibers.
Code: fiber_scheduler_interval_cleanup.rb
To validate the change, I put together a benchmark harness. I expected a bigger gain, but the improvement was fairly small (~5%).
Then I tried a second approach inspired by @serhii-sadovskyi’s PR #162: scheduling timeout cleanup on demand based on the nearest upcoming timeout.
Code: fiber_scheduler_on_demand_cleanup.rb
I benchmarked that version as well, and the improvement was in a similar range.
One representative run:
• mixed workload (successful + timed-out requests)
• the “work” is sleep (so async/non-blocking)
• 120 concurrent clients, running continuously for 45s

(I also ran longer and higher-concurrency tests with similar results)

+-------------------+-----------+---------+----------+----------+--------------+-------------+--------------+
| Implementation | Success % | Req/s | HTTP 200 | HTTP 408 | Max RSS (KB) | Max Pending | Peak Pending |
+-------------------+-----------+---------+----------+----------+--------------+-------------+--------------+
| original | 100.00 | 1335.07 | 47962 | 12002 | 80432 | 92 | 119 |
| interval_cleanup | 100.00 | 1399.53 | 52417 | 10448 | 78432 | 98 | 120 |
| on_demand_cleanup | 100.00 | 1387.23 | 49933 | 12382 | 79112 | 81 | 120 |
+-------------------+-----------+---------+----------+----------+--------------+-------------+--------------+

I was expecting a more dramatic difference 😅, so I may be missing something in either my expectations or the benchmark design.
Benchmark scripts are here:
https://github.com/rfronczyk/rage/tree/155_support_timeouts/scripts/bench

I’d really appreciate any guidance on:
• whether this benchmark setup is a good proxy for the reported issue, and
• what scenario would better expose the GC/timeout behavior you had in mind.

[rsamoilov]

That's actually something we've discussed with Serhii previously. And the upshot is that I can't reproduce the GC behaviour anymore 😆

The timeout_after method was commented out since the very inception of Rage - there were a lot of issues back then while I was trying to make the fiber scheduler work. It is possible the issue was actually not related to the timeout_after method itself.

I'll check out your benchmarks and implementations this week. It looks very exciting!

[rfronczyk]

That's actually something we've discussed with Serhii previously. And the upshot is that I can't reproduce the GC behaviour anymore 😆

The timeout_after method was commented out since the very inception of Rage - there were a lot of issues back then while I was trying to make the fiber scheduler work. It is possible the issue was actually not related to the timeout_after method itself.

I'll check out your benchmarks and implementations this week. It looks very exciting!

Thanks for letting me know! Maybe it's a time to just uncomment this feature :D