Bug 313673

Summary: API to perform asynchronous resource refresh
Product: [Eclipse Project] Platform Reporter: James Blackburn <jamesblackburn+eclipse>
Component: ResourcesAssignee: Platform-Resources-Inbox <platform-resources-inbox>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3 CC: ADewar, aleherb+eclipse, amolochnikov, andrew.hunt, angvoz.dev, bhawkes, dak2009, eclipse.sprigogin, jamesblackburn+eclipse, kellyc, malaperle, mober.at+eclipse, rcleveng, recoskie, tparker, wb-rel, wbprio, yevshif
Version: 3.6Keywords: api
Target Milestone: ---   
Hardware: PC   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 265504    

Description James Blackburn CLA 2010-05-20 04:42:27 EDT
We'd like API to allow users to request best-effort asynchronous refresh of resources.

+++ This bug was initially created as a clone of Bug #244979 +++

(In reply to bug 244979 comment #11)
> 2) core.resources uses refreshManager to refresh the workspace piece-meal
> asynchronously. There's no way for consumers to use this i.e. they're blocked
> until refreshLocal(...) is finished.  The particular IResource (sub-)tree is
> locked for the entirety of refreshLocal().

I think adding API to schedule a background refresh on any resource would be a
valuable addition.  It does not solve all problems mentioned in this bug, but
it would help with the typical use case of external builders which need to get
the resource tree into sync again, but don't want to lock the workspace for a
long time.

======

The pattern we see again and again in CDT is:
  - Run some external tool
  - Schedule job to perform Resource#refreshLocal(...)

These are both in-efficient and lock the resource sub-tree for the duration of the refresh. Importantly we don't care that the resources are instantaneously up-to-date.

If the platform could provide API to do this, there could be the following optimisations:
  - If the resource is contained in a tree which already has a (non-polling) IRefreshMonitor, and auto-refresh is on, then nothing to do.
  - If the resource, or parent of the resource, is already queued with the refresh Manager, nothing to do (RefreshManager already does this)
  - Otherwise queue the resource for refresh.
Comment 1 Martin Oberhuber CLA 2010-05-20 09:15:17 EDT
I agree that it would be good to have API for this.

In terms of implementation, perhaps it could work to have a special kind of RefreshMonitor which accepts asynchronous refresh requests via the API and enqueues / forwards them to the RefreshManager?
Comment 2 Eclipse Webmaster CLA 2019-09-06 16:09:31 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.