Bugzilla – Full Text Bug Listing
| Summary: | IStatusMonitor should allow a "cancel listener" to be added. | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Pawel Piech <pawel.1.piech> |
| Component: | Debug | Assignee: | Platform-Debug-Inbox <platform-debug-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
This would be hard to add to IRequest, as this is a public interface that clients can implement. So, it would need to be added to a specialization of IRequest, perhaps in the IViewerUpdate. Tagging with the controversial LATER resolution. We're following the progress monitor pattern here. When is this "not practical"? It seems that the "processor" processing a request can poll the cancel state peridically (before it does the next chunk of work). As well, the "requestor" waiting for the request can check if the request was canceled when a request is done (I don't think it needs the callback). I would prefer not to implement this, and remain consistent with the progress monitor. It would be great if IProgressMonitor accepted listeners too :-) We have two cases where polling is problematic: 1) First, in our debugger back end supports cancellation of some requests. The back end is out-of-process so we can't poll the IRequest.cancel() from there. This leaves us with interval polling which is complicated and not very performant. 2) The DSF architecture utilizes objects similar to IRequest (RequestMonitor) which allow clients to wait for data from a service. At each level that the request is serviced, there is often a new RequestMonitor created which when completed invokes the RequestMonitor from the client. So if a client request is canceled, logically the lower level request is canceled as well. We can implement this without having a listener that this bug requests. For most cases there is a one-to-one or one-to-many mapping between a UI level request for data, and corresponding command(s) for the data to the back end. However, for commands that retrieve ranges of data, coalescing allows multiple client requests to be combined into a single target side request. If one of the client-side requests is canceled, the range of data to be retrieved can be reduced. This breaks the simple implementation of "if client request is canceled so is the target request", and I hoped to fix it by having the cache manager listen to the cancel event and re-coalese the target side requests. As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. |
This is also a post 3.3 request: It would be helpful to be able to listen for when a request from flexible hierarchy has been canceled, because in some situations polling for the isCanceled() status flags is not practical. I would suggest that a simple interface interface ICancelListener { canceled(IRequest request); } be added, and addListener()/removeListener() methods be added to IRequest, when flexible hierarchy views get added to it.