Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Anyways, RunnableManager's pools MUST NOT inherit any variables,
IMHO. I think you meant the same.
Exactly. And my modifications ensure this CAN NOT happen, by simply
suppressing the automatic inheritance of environment stack between
child threads and their parent.
Ok, Good. But now there is an incompatibility - hope you mention it at
least in status file.
Yep, I will. In the meantime, I've seen that DefaultIncludeCacheManager
in 2.2 uses RunnableManager instead of "new Thread()", which is buggy as
the thread used to load the URI won't inherit the environment of the
request processing thread.
So I decided to refactor the CocoonThread I just added in a
CocoonRunnable, which wraps a Runnable and sets up the environment stack
before calling the wrapped object's run() method. That allows to use
both "new Thread()" and thread pools.
For places where we *need* inheritance to happen such as in parallel
include transformer, we now MUST use CocoonThread that does the
environment stack copy, thus preserving the information needed to
correctly resolve URIs in background threads. And in that case, we
cannot use RunnableManager since its threads don't (and shouldn't)
inherit the environement stack.
IncludeTransformer does not rely on inheritable thread locals, as it
is now. It used to, though.
Note that with the InheritableThreadLocal, thread had no choice but
inherit the environment stack of the parent thread. And using runnable
manager means using a inherited context which isn't the right one. The
CocoonRunnable should fix this.
What's missing? :-?
The asynchronous nature of threads combined with the create-on-demand
behaviour of pools.
Gotcha.
Yeah, not easy :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
