Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 354268 - Thread "Compiler Processing Task" is still affected by bug 322928
Summary: Thread "Compiler Processing Task" is still affected by bug 322928
Status: RESOLVED WORKSFORME
Alias: None
Product: Objectteams
Classification: Tools
Component: OTEquinox (show other bugs)
Version: 2.0   Edit
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: 2.8.2   Edit
Assignee: Stephan Herrmann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-09 11:41 EDT by Stephan Herrmann CLA
Modified: 2023-07-11 17:22 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Herrmann CLA 2011-08-09 11:41:50 EDT 
Bug 322928 mentions that under OT/Equinox threads that are explicitely
created/started given a plain Runnable still have a problem.

This effects only OT/Equinox settings because in plain application mode
the OTRE weaves into all run() methods, whereas OT/Equinox doesn't look
into all classes.

In real life the thread "Compiler Processing Task" is a victim of the
current incompleteness of our solution. This thread is started by
org.eclipse.jdt.internal.compiler.ProcessTaskManager and if 
deactivate() + activate() is called for a team, activation is not
restored for that particular thread.

Bug 322928 also mentions that this situation is rare within the Eclipse SDK.
But here we have a relevant witness. Not sure if a general solution is
feasible or if we should add special case behavior for this thread.
Comment 1 Stephan Herrmann CLA 2018-06-05 16:19:39 EDT 
Bulk move to 2.8
Comment 2 Stephan Herrmann CLA 2020-03-06 16:59:23 EST 
bulk move to 2.8.1
Comment 3 Stephan Herrmann CLA 2023-07-11 17:22:23 EDT 
The original mechanism as of bug 322928 was dropped during the migration bug 406518, and later re-implemented in bug 413857 (which actually links here).

Later bug 493556 introduced the option to restrict thread weaving to one of { Never, Base, Always }

Given that bug 413857 did include handling of Runnable implementations, I'm assuming this issue to be fixed.

Additionally, team org.eclipse.objectteams.otdt.internal.compiler.adaptor.CompilationThreadWatcher (from the initial commit) seems to address this same issue of extending activation to the newly created thread.

I'm reluctant, however, to remove the extendActivation() trick.