Log Message:
devel/ruby-async: update to 2.17.0

2.15.0 (2024-08-04)

* Allow transient tasks to exit completely. (#336)

2.15.1 (2024-08-07)

* Allow transient tasks to exit gracefully. (#337)

2.15.2 (2024-08-07)

* Transient tasks should only be stopped once. (#338)

2.15.3 (2024-08-08)

* Ensure that defer_stop resets state. (#339)

2.16.0 (2024-08-23)

Better Handling of Async and Sync in Nested Fibers

Interleaving bare fibers within Async and Sync blocks should not cause
problems, but it presents a number of issues in the current implementation.
Tracking the parent-child relationship between tasks, when they are
interleaved with bare fibers, is difficult.  The current implementation
assumes that if there is no parent task, then it should create a new
reactor.  This is not always the case, as the parent task might not be
visible due to nested Fibers.  As a result, Async will create a new reactor,
trying to stop the existing one, causing major internal consistency issues.

I encountered this issue when trying to use Async within a streaming
response in Rails.  The protocol-rack uses a normal fiber to wrap streaming
responses, and if you try to use Async within it, it will create a new
reactor, causing the server to lock up.

Ideally, Async and Sync helpers should work when any Fiber.scheduler is
defined.  Right now, it's unrealistic to expect Async::Task to work in any
scheduler, but at the very least, the following should work:

    reactor = Async::Reactor.new # internally calls Fiber.set_scheduler

    # This should run in the above reactor, rather than creating a new one.
    Async do
      puts "Hello World"
    end

In order to do this, bare Async and Sync blocks should use Fiber.scheduler
as a parent if possible.

See #340 for more details.

2.16.1 (2024-08-26)

* Add timeout to timeout error message.

2.17.0 (2024-09-05)

* Introduce Async::Queue#push and Async::Queue#pop for compatibility with
  ::Queue.