Community
Participate
Working Groups
Created attachment 93158 [details] patch so the UI is not blocked when creating a prebuilt index Build ID: 4.0.3 Steps To Reproduce: We are generating PDOMs on demand by the use for specific folders of SDKs (e.g. indexing all the includes for an entire source base). When we are doing is creating a dummy project to run the indexer on and then want to delete the project when it's complete. However, creating indexes can take some time and currently joining the indexer before copying the PDOM blocks the user from the UI. More information: One solution is to wrap the join to the indexer up in a job, which the patch does. Note, this patch also deletes the project when completed. Another solution I looked at was using the IIndexChangeListenter but: 1) The docs say don't use the interface and 2) It doesn't tell you how the indexer went idle (e.g. completed versus user cancelled). Ideally I'd like a listener that I could get whether or not the index was user cancelled and whether or not we should delete the dummy indexer project when complete. But for now, the attached solution suits our needs but it would be good to have a better solution for CDT 5.0.
I'm a little confused - the indexer backend doesn't start jobs on the ui thread so the client code must be doing this? If this is correct then is it possible to invoke the whole of GeneratePDOM in a job? (is this the entry point you are using?) Cancellation could be handled by having a non NullProgressMonitor passed to joinIndexer. The issue here is that pdom tasks (tasks are a cdt level concept) are batched up and processed inside a single job, so progress reflects the job and not the single task we're interested in. Even with the warning, IIndexChangeListener and IIndexStateListener are public API in the same way that IIndex is - they should be stable enough to use.
(In reply to comment #1) > I'm a little confused - the indexer backend doesn't start jobs on the ui thread > so the client code must be doing this? If this is correct then is it possible > to invoke the whole of GeneratePDOM in a job? (is this the entry point you are > using?) I tried this. When the join is performed on the indexer a dialog appears saying that a user job is waiting to be finished. Doesn't matter where I wrap the job, I found I need to wrap the join itself.
Created attachment 98326 [details] Patch for CDT 5.0 Here's the patch for CDT 5.0. As well, the previous call to: if (!im.isIndexerSetupPostponed(cproject)) ...was causing the join to fail becuase the project wasn't created yet, so it always returned false. Hence the PDOM was copied even before it started indexing. On the side issue, passing a sub progress monitor to the join doesn't help b/c the indexer job knows nothing about it to set it to canceled, so there's still the issue that a user cancel will be unknown, but that is a separate issue from this one right now.
I think its possible to wrap the entire GeneratePDOM.run() in a job, and launch it from a non-UI thread. The dialog popping up is a side effect from creating a new project as the helper methods in CCorePlugin initiate a new job in the background (to refresh the workspace) - see the implementation of org.eclipse.cdt.core.CCorePlugin.createCProject(IProjectDescription, IProject, IProgressMonitor, String) Having createCProject refresh the workspace in the foreground avoids this problem, so I think this is the way to go. I agree about the progress monitor suggestion. I've not been able to get the cancelled status from the PDOMIndexerJob either so far.
(In reply to comment #4) > Having createCProject refresh the workspace in the foreground avoids this > problem, so I think this is the way to go. To clarify, we can't change the existing implementation's behaviour as it is there for a reason (see 84606), but maybe we can add a wrapper method to allow specifying whether or not this happens, or in the worst case it can be cloned in the IExportProjectProvider.
OK, I can move the Job up a level so I suppose this bug can be ignored. The problem that the copy occurs (the join fails) before the indexer is complete still exists as well as no ability to detect monitor status on the indexer job. I can open separate bugs for those if you want. Maybe if there was a way to kick on the indexer directly it could be done with a progress monitor you have access to, but I didn't see any way to do this.
(In reply to comment #6) > The problem that the copy occurs (the join fails) before the indexer is > complete still exists sorry, I missed this in comment #3. From investigation, the race condition was: main: GeneratePDOM calls createProject main: workspace notify listeners main: cmodel listener main: add project: ----> Job forked to add tasks (originally we did this synchronously) main: join (Job may not have registered tasks at this point) I've checked in a fix which guarantees that the indexing tasks have been enqueued before we attempt the join. > well as no ability to detect monitor status on the indexer job. > I can open separate bugs for those if you want. A new bug for this one would be good thanks > Maybe if there was a way to kick on the indexer directly it could be done with > a progress monitor you have access to, but I didn't see any way to do this. Yes, I'd like to get Markus's input in the new bug as there is a single job for all indexing tasks - this means even if we do have access to the indexer progress monitor, we could be looking at the progress for indexing several projects (especially running with the workbench). For example, you might have (1) User-initiated PDOM generation task (2) incremental update of user project and the user cancels during (2). As we have the progress for the single indexer Job, we cannot distinguish which tasks finished and which were cancelled. With that in mind, it might be better to generate additional events from the indexer.
created bug 229989, bug 229992. I don't see any commit for this ( checking from here: http://download.eclipse.org/tools/cdt/builds/cvslog/HEAD/index.html): >>I've checked in a fix which guarantees that the indexing tasks have been enqueued before we attempt the join. Maybe the log has not be updated yet? I changed status to WONTFIX since there's an alternate workaround and side-issues are moved to other bugs.
Created attachment 98464 [details] patch applied to HEAD (In reply to comment #8) > Maybe the log has not be updated yet? hm, it looks like that's the case - the changes are definitely in there. Only GeneratePDOM and PDOMManager were altered. I've attached the patch that I checked in - the history log says 15:54 (I'm assuming that's BST) > I changed status to WONTFIX since there's an alternate workaround and > side-issues are moved to other bugs. thanks
