[tannevaled]

Net::FTP releases the GVL, and a gate so the next binding cannot forget

Stacked on #921 (ftp-bound-reads); the diff to review is the last three
commits.

What this changes

Net::FTP's control connection now runs its blocking socket calls inside
ioBlock, the same wrapper Net::HTTP has used at twenty sites since it was
written. rbgo emulates a GVL, so a native call that blocks while holding it
stops every other Ruby thread.

The cost was never a slow program, it was a deadlock. A Ruby program that
serves itself — a spec fixture, a test that binds a socket and connects to it,
an embedder running a listener beside its own client — has its server thread
return from Accept and then park on a lock the client is sitting on.

Proved by dose-response rather than by correlation, because "stuck or merely
late?" is a question only a clock answers:

client deadline	accept completed at
2 s	2.308 s
5 s	5.307 s
with ioBlock	0.305 s

The accept was not slow. It was waiting for the client to give up.

⛔ Two limits I am not going to bury

1. This does not fix #916. The library/net-ftp specs are byte-identical
after the change: still 39 killed by the clock, still 459/17, still −442. The
GVL release is proved on a minimal reproduction and it is necessary, but at
least one more cause remains and it is in the spec-harness path. I am saying so
here rather than letting a green PR imply the issue is closed.

2. My own FTP fix was incomplete, and the gate caught me, not the other way
round. I wrapped the control connection and left the data connection
(Dial / Accept / ReadString) holding the GVL. The gate saw it; I did not.
Those three sites are in the backlog below, unfixed and named.

The gate

TestEveryBlockingSocketCallReleasesTheGVL walks the AST of every
non-test file in internal/vm (542 files, 27 blocking calls) and asks the
question that actually matters. "Is ioBlock implemented?" was always the wrong
one — it was implemented, and correct, for years. The right question is "who
else should be calling it?", and that is answerable statically: a blocking
socket call in a binding must sit lexically inside a closure handed to
ioBlock / threadBlock / threadRelease.

This is the defect shape this repository has now produced eight times in one
week: a mechanism that exists and is wired at only some of its doors
(Array.new vs Array#first; expand_path vs Dir.home; raiseWithIvars vs
Kernel#raise; paren-FCALL vs the vcall flag; Set's constructors; the stub
list across three surfaces; the README's derived numbers; and now ioBlock in
Net::HTTP but not Net::FTP). A lesson that recurs is a missing gate, not a
missing note, so it is a gate.

It lands as a ratchet, not a big bang

It was written after the fact and finds sites in five bindings at once. Failing
on all of them would have meant either a sprawling change nobody can review or
— far more likely — the gate never landing at all.
testdata/gvl-blocking-backlog.txt records what was already there on the day it
was written, so the gate fires on what happens next. The list may only
shrink: an entry that stops reporting also fails, because a stale allowance
is exactly where the next regression hides.

What it found beyond FTP:

site	what it is
net_ftp_bind.go ×3	the data connection my own fix missed
net_imap_bind.go ×2	readLine/readLiteral passed as callbacks, no ioBlock at all — FTP's shape exactly
net_smtp_bind.go	the response reader
httprb.go, hanami_bind.go	two Accepts: an embedder running one beside its own client is the deadlock above

The exemption is named, never inferred

A purely lexical rule cannot see a helper whose callers wrap it. I claimed
mid-review that Net::HTTP had four unwrapped sites; that was wrong — all
six findings there are helpers reached only from inside an ioBlock. So the
waiver is explicit, //gvl:released-by-caller <reason>, and the reason is
required: a bare directive is a silent waiver, and silent waivers are how
Net::FTP went twenty sites without the wrapper everything else had. It also
keeps every exemption readable in one grep instead of hidden in an
interprocedural inference nobody can audit.

Controlled in both directions

Removing the single ftpIO wrapper makes the gate name net_ftp_bind.go:249
immediately. And it refuses to pass on silence: if it parses zero files or finds
zero blocking calls it fails, because an unread tree and a clean one look
identical from the outside.

Also here

The two functions #921's first coverage pass left uncovered — ftpApplyOpts's
open_timeout door and ftpTimeoutErr's two raises. That pass did not move the
measurement; this one was measured before pushing (go tool cover -func: both
100.0%).

Refs #916

🤖 Generated with Claude Code