gvl: release GVL during streaming I/O, re-acquire for Ruby block yields

[ruyrocha]

Previously, chunks used Yield::Iter over a BodyReceiver iterator. BodyReceiver::next called maybe_block_on, which held the GVL across the entire Tokio future — blocking all other Ruby threads for the duration of each network wait.

Replace with a Rust-driven loop inside nogvl_cancellable:

• GVL is released while polling the async byte stream (network I/O)
• GVL is re-acquired via with_gvl + block_in_place only to yield each chunk to the Ruby block
• Thread interruption via Thread.kill is handled at every iteration step through the existing cancellation flag
• Streaming errors now propagate as Ruby exceptions instead of being silently swallowed by the and_then(|r| r.ok()) in the old iterator

Add gvl::with_gvl as the counterpart to nogvl/nogvl_cancellable, add rt::runtime() to expose the global Tokio handle, and remove rt::maybe_block_on which is no longer needed.

The Ruby block Proc is pinned against GC for the duration of streaming via rb_gc_register_address.

Fixes #57

[0x676e67]

No GVL is held during the maybe_block_on call; it only releases the GVL.
You’re correct about one thing: and_then(|r| r.ok()) swallows timeout errors, which definitely needs a proper solution. However, iterators don’t natively support returning a Result under normal circumstances — only Option is possible.

[0x676e67]

This PR is not related to the issue at https://github.com/SearchApi/wreq-ruby/issues/57.
Our intention is to access the Ruby GVL within Rust threads to iterate over the user's request stream Body, but what is being implemented here is for the Response Body.

[ruyrocha]

@0x676e67 It seems they're going to be two separate issues.

I'll drop the Fixes #57 reference and reopen this as a standalone response streaming fix. I'd then like to take a proper pass at the actual issue allowing Rust threads to drive iteration of a Ruby-side request body via the GVL. Before I do that: is the expectation that the caller passes an Enumerator, any object responding to each, or something else? And should Rust pull from it synchronously per-chunk or register a callback?

[0x676e67]

ruyrocha

Yes, but we're putting this issue on hold for now (it doesn't seem easy to implement; it would require embedding the Ruby interpreter and handling interpreter initialization). However, PRs are welcome. We’ll only revisit this when we seriously consider releasing v2.

[0x676e67]

A quick hint: if you've ever worked with PyO3, you'll understand the details. GVL is analogous to GIL—we also need to avoid blocking Rust async threads with GVL during iteration. You can check this out:
https://github.com/0x676e67/wreq-python/blob/58751c59bf00b2bf30b4b8ebb2dbe386348df59d/src/client/body/stream.rs#L213

[ruyrocha]

@0x676e67 I never used PyO3 before :)

I think the main gotcha here is around the differences between GVL & GIL, and no equivalent APIs. Instead of trying to acquire the GVL from a Tokio thread, spawn a genuine Ruby thread via rb_thread_create(). This thread naturally holds the GVL and can call Ruby APIs. It releases the GVL only when waiting for channel capacity (so other Ruby threads can run), and re-acquires it for the next .next call

[0x676e67]

@0x676e67 I never used PyO3 before :)

I think the main gotcha here is around the differences between GVL & GIL, and no equivalent APIs. Instead of trying to acquire the GVL from a Tokio thread, spawn a genuine Ruby thread via rb_thread_create(). This thread naturally holds the GVL and can call Ruby APIs. It releases the GVL only when waiting for channel capacity (so other Ruby threads can run), and re-acquires it for the next .next call

That's a solid idea. Magnus should provide APIs for this. We generally avoid using rb-sys unless absolutely necessary, as it contains numerous unsafe APIs and requires extreme caution.