See #893 for the details of the bug.
To reproduce the bug (before this is merged), open the 'Custom' catalog prefs pane, invoke QS and press ⌘R repeatedly 'til everything disappears.
reload catalog tables on the main thread. Fixes #893
Do you want to wait for #1276 so you can use [self reloadData]?
Actually, the two can't be combined exactly, since they do slightly different things. I'll leave this open, and it can be merged independently of #1276 (unless you see a better way round it)
Tried to reproduce the bug after this was merged (to make sure it was fixed) and hitting ⌘R repeatedly seems to beach ball QS indefinitely. I also found another problem through pure dumb luck. If you're in Custom and try to drag an entry to reorder them, it beach balls then too.
Dragging to reorder catalog entries does it for me every time. Closed Xcode, switched branches, opened Xcode, did a clean, then ran it. The drag appears to succeed (based on the position of things after a relaunch) but the UI becomes unresponsive.
I thought it might have been the Synonyms I had in my catalog (since this branch has no support for them), but removing them made no difference.
Oh, and as for your questions, I'm not sure. If you're on the main thread and want something else to run on the main thread, wouldn't you just run it? Or do we not necessarily know which thread this will be called from?
Cleaned and tried again. Now simply opening the Catalog prefs seems to be enough to lock things up. When I quit via Activity Monitor, the debugger pauses here:
Based on this, and some NSLogging I did, the method is called in response to the notification, but the block is never executed.
Run main thread blocks from a background thread
Yesh, that's what I thought. Try the extra commit I've just pushed. It's what I said in the first bullet point above
Looks like a similar goal here: http://stackoverflow.com/a/12850706/491598
My completely uneducated opinion is that we should test isMainThread as he does (and as you suggested) instead. Going to another thread only to come back seems like a lot of overhead, and I know we're dealing with modern systems, but can we always be guaranteed that more than one thread can exist?
Reminder: use this function once this is merged, and release is merged into master
If I try and rebase this and #1276 against master, I get a merge conflict. Can we just merge these and I'll do the change afterwards?