views:

33

answers:

2

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();"?

A: 

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.

Mark Peters
look like you understand the question correctly. I want vote up your answer, but have no right reputation.
vitali_y
A:classX:f0(); // will call some eclipse function internally
vitali_y
B:classZ:f2(); // we will - get in the function - as result
vitali_y
so if B:classZ:f2(); will modify - for example:Thread.currentThread().setContextClassLoader(XXX);and doesn't restore it original value before return - we will get wrong context class loader inA:classX:f0();
vitali_y
@vitali_y: Yes, I imagine you are correct that if one Thread sets the context class loader but does not restore it, it will remain for other plugins that run code on the same thread. As for upvoting, you need to have 15 rep before you can upvote. As the asker, however, you can accept an answer if it correctly answers your question (using the checkmark beside each answer).
Mark Peters
A: 

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.

M. Jessup
+1 for having a good answer but -1 for it having absolutely nothing to do with the question. Not that I blame you, the original question was difficult to understand.
Mark Peters