objc: an AppKit event loop a caller can leave

[tannevaled]

-[NSApplication run] cannot be left on demand. stop: sets a flag AppKit reads only after it finishes processing an event, so an application with nobody touching it waits for an event that is never coming. StopApp, added an hour ago, wakes the run loop — and it is still not enough, because waking a run loop is not an event either. Measured: the desk still hung, and the goroutine dump showed the work finished, the waiting goroutine gone, and the main thread still inside run.

RunAppLoop is the loop run runs, written out: take the next event, send it, and between the two ask the caller whether to carry on. Waking the main run loop makes the wait return nil, the caller is asked, and one that says stop gets its thread back at once — with no event, no mouse movement and nobody at the machine.

It is not a pump. -[NSApplication sendEvent:] is what tracks a menu and drives a window; sampling the run loop instead gives a menu-bar item whose menu never opens, which this fleet has already paid for once.

Every argument in it is an integer, a pointer or a bool, and that is not an accident: the obvious way out of run is to post an application-defined event, and +[NSEvent otherEventWithType:location:…] takes an NSPoint and a timestamp — three doubles, in floating-point registers, through a bridge that passes everything in integer ones.

Half of it is tested here, and the comment says which half and why. The wake-up reaches the main thread's run loop, and go test runs every test on a goroutine of its own, so a test can lock itself to a thread but never to that one. A test written against it hung for ten minutes, which was the correct answer. The other half is verified in the program that needed it.