[EclipseShell-developer] stdout discussion continued

[Lukasz S. <har...@op...>]

----- Original Message -----
From: "Werner Schuster (murphee)" <wer...@gm...>
To: <ecl...@li...>
Sent: Saturday, March 11, 2006 5:26 PM


(1)
> There's only one problem: the ExecutionEnvironments arent' restricted to
one Thread per ExecutionEnvironment, ie. whenever I execute
> a statement, a new Eclipse Job which will execute it (the Eclipse Job
system is basically a Worker thread system, that uses a thread
> pool); so potentially, every code executio will happen in a different
thread.
(2)
> Even if I could fix that, then it's still possible that the code executed
in the ExecutionEnvironment will create several threads,
> and their output should go to the same Output Stream. Hmm... although...
come to think of it: this should be solved by the fact that you
> used *Inheritable*ThreadLocal... so all child threads should have the same
OutputStream...

murphee, do you agree that two problems above are quite easy to solve as I
wrote in a mail to you?
(1) - I mean associating given console with some information from the
ExecutionEnvironment context (e.g. editor name).
(2) - InheritableThreadLocal in fact solves problem with child threads.

> Other problem: code from an ExecutionEnvironment that gets executed on a
different Thread; best example would be code that's called
> from the UI thread; that's necessary for all GUI modifications in SWT (and
Swing), ie. as soon as you change anything in an SWT component,
> you need to do it on the GUI EventDispatchingThread (using
Display.syncExec(Runnable)).
>

This seems to be unsolvable in general - it will be very difficult (maybe
even impossible) to mess with e.g. EventQueue.invokeLater(Runnable) -
because it's in java.* hierarchy and cannot be loaded by class loader other
than bootstrap class loader. Hence we can't modify it's bytecode.
We could try to apply some aspects on code which calls the EventQueue
methods. If we have source code with calls to these methods then weaving
shall be quite straightforward - I'm not sure what would be in case of
weaving aspects into bytecode (when we don't have the sources) - would this
capture properly all invokations or not.

On the other side - if the class being called wouldn't be in java hierarchy
(let it be javax.swing.SwingUtilities instead) then we can try to add an
aspect to it which would be able to match Runnable classloader to the proper
console. Of course each Runnable instance would be created by custom
classloader - we have to ensure that each ExecutionEnvironment will have its
own classloader to load Runnable class. Then we could take this classloader
in weaved invokeLater method, find the ExecutionEnvironment and then the
actual console.

When I'll have a little time I'll try to play with aspects..

And of course - when we send a Runnable to another thread (not created by
us) the call stack is unusable for our purposes.. No info about caller is
supplied there...

Regards,
Lukasz