Eclipse plungins and threads

I get a question and do not know where to find a correct answer. The hypothetical problem is next: there is 2 unrelated eclipse plugin A and B. A and B were developed by 2 independent developers. Let plugin A call some internal eclipse code. is it possible that we get in some function in B with the same thread. i.e. the stack trace will look like:

B:classZ:f2(); ... eclipse:classY:f1(); ... A:classX:f0();

could your please point example if this is possible...

i.e. is it possible 开发者_如何学编程or not Thread.currentThread() in "A:classX:f0();" is the same as Thread.currentThread() in "B:classZ:f2();"?

I don't see why not. Say B contributed a generic working set view and A contributes a new concrete type of IResource. B's code to render the view could call Eclipse's working set framework to get the IResource names, which would call into A's implementation of IResource.getName().

I don't recall there's any explicit sandboxing of plugins in a thread, though it's been a really long time since I did any plugin development. My assumption is it would make the concepts of extension points almost impossible to implement if one plugin could not dynamically link to another plugin's code.

Now obviously if A and B are developed completely independently you might not be able to have a static link, but we're not talking about that.

If you just wish to chain the calls together then they will always run in the same thread unless one piece of code spawns its own threads: i.e. if you say

A:foo.doSomething();
B:bar.doSomethingElse();

both calls will always be run in the same thread (or at least start their, however they may spawn their own threads).

It is, however not possible to have code specify which Thread it wishes to run in i.e. IN seperate execution paths that are not occuring in the same thread:

A:foo.doSomething(commonThread);

and in a different thread where "commonThread" is a shared Thread object.

B:bar.doSomethingElse(commonThread);

What you have to do is have the Thread where you want the code to run execute be able to accept tasks that you want to have run in that thread. This is how things like SwingUtilities.invokeXXX(Runnable r) work to get things on the EDT. Here is a rough example of what this might look like (note this is a quick example and not entirely correct/robust)

class WorkerThread implements Runnable{

  BlockingDeque<Runnable> tasks = ...;

  Thread t;

  public void startWorker(){
    if(t != null && t.isAlive())return;
    t = new Thread(this);
    t.start();
  }

  public void run(){
    while(true){
       Runnable nextTask = tasks.getFirst();
       nextTask.run();
    }
  }

  public void doTaskInThread(Runnable r){
    if(Thread.currentThread() == this.t){
       //already in the worker thread, do immediately
       r.run();
    }else{
       //not in the worker thread so queue
       //alternatively eliminate the first test condition and always queue
       tasks.push(r);
    }
  }
}

While it may be possible to engineer something like the above into the code it would likely be very difficult especially if you do not have access to the source for all of the plugins you wish to control.