platform-core-home/documents/auto_refresh.html
Parent Directory
|
Revision Log
Revision 1.1 - (view) (download) (as text)
| 1 : | johna | 1.1 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| 2 : | <html> | ||
| 3 : | <head> | ||
| 4 : | <title>Auto-refresh overview</title> | ||
| 5 : | <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css"> | ||
| 6 : | </head> | ||
| 7 : | <body text="#000000" bgcolor="#FFFFFF"> | ||
| 8 : | |||
| 9 : | <h1>Auto-refresh overview</h1> | ||
| 10 : | <font size="-1">Last modified: February 20, 2004</font> | ||
| 11 : | <p> | ||
| 12 : | In Eclipse 3.0 an auto-refresh facility was added to the | ||
| 13 : | org.eclipse.core.resources plugin. This feature, when enabled, searches | ||
| 14 : | the file system for changes that have been made externally, and then | ||
| 15 : | automatically refreshes the workspace when new changes are discovered. This | ||
| 16 : | document briefly describes the architecture of auto-refresh. | ||
| 17 : | </p> | ||
| 18 : | <p> | ||
| 19 : | Plug-ins provide change notification to the workspace by hooking into the | ||
| 20 : | new <tt>refreshProviders</tt> extension point. Extensions to this extension | ||
| 21 : | point implement subclasses of the following abstract class: | ||
| 22 : | <pre> | ||
| 23 : | public abstract class RefreshProvider { | ||
| 24 : | public abstract IRefreshMonitor installMonitor(IResource resource, IRefreshResult result); | ||
| 25 : | } | ||
| 26 : | </pre> | ||
| 27 : | </p> | ||
| 28 : | <p> | ||
| 29 : | When a new project or linked resource is added to the workspace, each installed | ||
| 30 : | refresh provider is asked to install a refresh monitor on that location. If for any | ||
| 31 : | reason a refresh provider is not able to monitor a given location, it can opt not to | ||
| 32 : | return a monitor. If no installed refresh providers are willing to monitor the location | ||
| 33 : | (or if no refresh providers are installed), a default refresh provider is implemented | ||
| 34 : | by the platform. This default refresh provider uses a naive Java-based polling | ||
| 35 : | loop that manually checks for changes in the location at a specified interval | ||
| 36 : | (by default, 30 seconds). | ||
| 37 : | </p> | ||
| 38 : | <p> | ||
| 39 : | Once installed, a monitor is responsible for notifying the workspace when external | ||
| 40 : | changes are made to that file system location by invoking methods on the provided | ||
| 41 : | callback interface (<tt>IRefreshResult</tt>). The results are collected by the | ||
| 42 : | workspace, and the workspace will synchronize the changed resources in | ||
| 43 : | a periodic background job. Note that this hand-off is entirely asynchronous. | ||
| 44 : | The monitor is responsible for identifying out of sync resources, and in a separate | ||
| 45 : | thread the workspace will process those changes and reconcile them with | ||
| 46 : | the workspace tree. | ||
| 47 : | </p> | ||
| 48 : | <p> | ||
| 49 : | The Eclipse SDK includes refresh provider implementations for both Win32 and Linux | ||
| 50 : | platforms. On all other platforms, the default Java-based polling refresh provider | ||
| 51 : | is used, unless another plug-in is installed that provides a more efficient | ||
| 52 : | platform-specific implementation. On Windows, the refresh provider uses win32 | ||
| 53 : | API calls to install a native file system monitor (FindFirstChangeNotificationW | ||
| 54 : | in windows.h). File system monitors in win32 are <b>deep</b>, i.e., they report | ||
| 55 : | changes on an entire file sub-tree. | ||
| 56 : | </p> | ||
| 57 : | <p> | ||
| 58 : | On Linux, the refresh provider use a standard Unix utility | ||
| 59 : | called FAM (File Alteration Monitor), that is installed by default on most Linux | ||
| 60 : | distributions. FAM runs a daemon that uses a native polling loop to detect changes in | ||
| 61 : | the file system. Clients can install a monitor on individual directories, and they are | ||
| 62 : | provided with a change event queue that they can process at will (either with a blocking | ||
| 63 : | dequeue operation or by peaking at the queue in their own polling loop). FAM | ||
| 64 : | monitors are <b>shallow</b>, i.e., you need to install separate monitors on | ||
| 65 : | each folder of a sub-tree. | ||
| 66 : | </p> | ||
| 67 : | |||
| 68 : | |||
| 69 : | |||
| 70 : | |||
| 71 : | |||
| 72 : | |||
| 73 : | </body> | ||
| 74 : | </html> |
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |
