Reload catalog tables on the main thread. Fixes #893 #1313

Merged
merged 2 commits into from Jan 17, 2013

2 participants

@pjrobertson
Quicksilver OS X member

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.

@skurfer
Quicksilver OS X member

Do you want to wait for #1276 so you can use [self reloadData]?

@pjrobertson pjrobertson closed this Jan 7, 2013
@pjrobertson
Quicksilver OS X member
@pjrobertson pjrobertson reopened this Jan 7, 2013
@pjrobertson
Quicksilver OS X member

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)

@skurfer
Quicksilver OS X member

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.

@pjrobertson
Quicksilver OS X member
@skurfer
Quicksilver OS X member

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.

@skurfer
Quicksilver OS X member

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?

@pjrobertson
Quicksilver OS X member
@skurfer
Quicksilver OS X member

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:

Catalog Hang

Based on this, and some NSLogging I did, the method is called in response to the notification, but the block is never executed.

@pjrobertson
Quicksilver OS X member

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

@skurfer
Quicksilver OS X member

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?

@pjrobertson
Quicksilver OS X member

Reminder: use this function once this is merged, and release is merged into master

@pjrobertson
Quicksilver OS X member

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?

@skurfer skurfer merged commit 270734b into quicksilver:master Jan 17, 2013
@pjrobertson pjrobertson deleted the pjrobertson:catalogScan branch Jan 17, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment