DispatchMain gives the block back

[tannevaled]

Every call leaked one Objective-C block and one entry in purego's block table — the entry that holds the Go closure alive — for the life of the process. Nothing ever removed either: purego's dispose helper is what deletes a table entry, and dispose only runs when the last reference to the block goes.

Measured

One process posting blocks and draining them on the main thread:

blocks posted	before	after
~3 500	14.2 MB	13.5 MB
~40 000	22.3 MB	17.8 MB
~160 000	44.4 MB	19.7 MB

Growth over the same span falls from +30.2 MB to +6.2 MB — about 200 bytes a call, previously never returned. An application that hops to the main thread once a frame reached the old numbers in minutes.

Releasing here is safe because dispatch_async takes its own reference, and must: its contract is that the caller may free the block as soon as the call returns.

The test's seam had to be completed, not just used

The scheduled-hop test fakes mkBlock with a sentinel. Leaving the real rmBlock in place sent 0xB10C to _Block_release and the suite died with fault 0xb114. A seam that is only half replaced runs half the real thing.

⚠ Not a fix for the crash this was found while chasing

go-xrkit/desk's suite faults inside cfRunLoopRunInMode at iokit hid_darwin.go:434, invoking a block that belongs to this package. With this change it still does — 2 runs in 10, against 4 in 10 before, which is one small sample inside another's noise. That is a separate defect and is filed as one.

🤖 Generated with Claude Code