[masklinn]

The GIL is there to protect the interpreter's internal data structures, so it's only necessary to hold it while running the interpreter (while executing ruby code) or manipulating interpreter internals.

This is all IO, there's no interpreter execution while you're waiting for an HTTP request to come back so the GIL is released before starting IO, and re-acquired after the request comes back (before resuming execution), same when executing native code which doesn't interact with the interpreter (e.g. image processing implemented in C).

The GIL is an issue when you have multiple interpreted (not native) CPU-bound threads (and depending on the exact strategy it may also be an issue when there's an interpreted CPU-bound thread and multiple IO-bound threads, CPython 3's "new GIL" has/had that problem)

Also MRI has a GIL, GILs are implementation details (with consequences, but still) and other implementations may or may not use a GIL.