Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322928

Summary:

per thread deactivation & activation fails to establish global activation

Product:

[Tools] Objectteams

Reporter:

Stephan Herrmann <stephan.herrmann>

Component:

OTEquinox

Assignee:

Stephan Herrmann <stephan.herrmann>

Status:

VERIFIED FIXED

QA Contact:

Severity:

major

Priority:

Version:

0.7

Target Milestone:

0.7.1

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
Proposed fixes	none

Description Stephan Herrmann

2010-08-17 12:25:12 EDT

In OT/Equinox if a team is activated for all thread then deactivated for an individual thread and then re-activated for that thread, activation no longer captures all threads.

This is due to the fact, that we fail to weave our calls to TeamThreadManager.newThreadStarted(), thus we don't know about all existing threads.

This occurred when working on bug 322898: at some point the callin bindings of OTTypeHierarchies stopped working.

Comment 1 Stephan Herrmann

2010-08-17 12:32:59 EDT

Created attachment 176809 [details]
Proposed fixes

This is a two-part fix:

* Let TransformerHook transform all classes (directly) extending j.l.Thread
  in order to weave in calls to TeamThreadManager

* For Worker threads, this comes too late, because class Worker is loaded
  very early. Instead we register a JobListener, that will call the
  TeamThreadManager directly, without relying on bytecode augmentation.

The original use case (type hierarchy view) works fine with this patch.

Comment 2 Stephan Herrmann

2010-08-21 17:10:31 EDT

The fix works fine in real-world usage, closing.

Comment 3 Stephan Herrmann

2010-09-10 17:17:47 EDT

CAVEAT: the current implementation only covers subclasses of Thread,
but the OTRE normally also weaves into implementors of Runnable.

Yet, I'm reluctant to extend the solution because of the sheer number
of Runnables (plus analysis currently only follows the superclass
chain, not super interfaces).

In Eclipse plugins directly invoking new Thread(runnable) is very rare.
In this context it might be safe to omit runnables from weaving.
However, this is not true for OSGi in general.

Comment 4 Stephan Herrmann

2010-09-23 17:17:52 EDT

Verified using I201009211735