Bugzilla – Full Text Bug Listing
| Summary: | [Progress] Automatic transfer of scheduling rules when spwaning modal context thread | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dirk Baeumer <dirk_baeumer> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | RESOLVED WONTFIX | QA Contact: | Prakash Rangaraj <prakash> |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | john.arthorne, martinae, susan |
| Version: | 3.1 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
Are you suggesting that we automatically transfer the scheduling rule owned by the UI thread every time a modal context thread is created? Note that JFace has no dependency on the job API (and won't be adding such a dependency). Yes, that's what I was asking for. If the UI thread is blocked after wards it doesn't make sense to keep any rules. If someone does a sync exec back from the modal context he can transfer the rules back. However, JFace not knowing about Jobs makes this difficult. But the pltform could plug-in a special rule tranferer. I'm not really keen on this idea. Owning locks and scheduling rules in the UI thread is generally bad because it prevents the UI from painting if the lock or rule is not available. We get around this by spinning a "free" event loop when the UI is blocked, but this has its own problems. I don't want to add any API that suggests owning locks in the UI thread is an acceptable thing to do. Dirk, why does the refactoring aquire locks already in the UI-thread? The current situation is a guaranteed source of deadlocks. As users of IRunnableContext.run(forked) can not make any assumtions about the locks held by their thread they must transfer them otherwise, it is a programming error. Isn't it the whole concept of the model context thread to run forked so that the UI can still be updated (and you don't have to run a extra event loop)? So maybe the locks should get moved, (not copied -> freed on the UI thread). Whouldn't it be better if the Job framework manages all that and doesn't let JFace create its own thread? Refactoring has to aquire the look in the UI thread. Otherwise it can't be guaranteed that the workspace doesn't change during the refactoring steps precondition checking, change creation and change execution. The actual execution of these steps take place in the modal context thread. John, what do you suggest then to solve this problem. Letting the client do all the work (especially in cases where the client isn't aware of this at all) doesn't seem to be the right solution either. My point is that acquiring a rule in the UI thread is not the common case. Requiring the client to do a bit of work to manage this lock transition isn't bad if refactoring is likely to be the only use case. But the code spawning the modal context thread may not know that it is called by something like refactoring. My model of how this works is that no real "work" happens in the UI thread. The rule is acquired in the UI thread, a dialog is displayed, and then the refactoring infrastructure creates a modal context thread to perform the precondition checks and the actual refactoring. In this modal all the participants are called from the modal context thread (in fact everything except actually displaying the precondition and preview dialogs is in the non-UI thread). From your description, it sounds like refactoring is calling participants in the UI thread, and then the participants are responsible for forking the modal context thread. Is there a particular situation where this is currently happening? There are currently no plans to work on this although we would be happy to review a patch Marking WONTFIX This was marked as WONTFIX. I don't know how it got reopened, as it doesn't show up as being reopened in the bug history. |
With IJobManager#transferRules and IThreadListener it is currently possible to transfer rules from the UI thread to the modal context thread. However, this is still error prone since the code spawning the modal context thread may not know about scheduling rules allocated outside of his scope. Consider the following example: IJobManager#beginRule(rule). ExistingOperation#do() IJobManager#endRule() ExisitingOperation#do() { IRunnableContext#run(......); } to make sure that this doesn't end in a dead lock the operation has to pass all the scheduling rules to the modal context thread. Couldn't this be done automatically by the ModelContext using the API IJobManager#getCurrentJob()#getSchedulingRule()