App: load AppKit where NSApplication is named - #9
Merged
Merged
Conversation
App names NSApplication and did not ensure AppKit was open, so a caller who forgot the load got a nil class, a nil application, and every message after it returning zero — in silence, because Objective-C does not complain about a message to nil. A menu-bar program built that way starts, prints its greeting and exits in a millisecond, with nothing on screen and nothing in a log. The load belongs with the name, not with each caller's memory. It is once and idempotent. Measured, and honestly incomplete: with this, a tray that entered [NSApp run] and returned in 0.01s now takes 0.53s. Something real changed, and the loop still does not hold. This is a defect fixed, not the defect found.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A caller who asks for the shared application should not also have to know
that AppKit must be dlopened first. This is the function that names
NSApplication; the load belongs with the name.Without it
ClassID("NSApplication")is nil,sharedApplicationis nil, andevery message after it returns zero — in silence, because Objective-C does not
complain about a message to nil. A menu-bar program built that way starts,
prints its greeting and exits in a millisecond, with nothing on screen and
nothing in a log.
That failure was diagnosed seven times before it was found, in
go-widgets/tray, which reached the point of running its own event loop on anil application. The traces read
isMainThread=1 app=0 item=0: the thread wasright, the object was nothing.
Once released,
go-widgets/traycan drop its ownensureAppKit()(seego-widgets/tray#9).