Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
- core: DefaultRunnableManager
The thread pool can be created lazily when the first Runnable is
executed.
Resulting pool will not behave same as with eager loading, for two
reasons:
(1) there are 5 references to InheritableThreadLocal in Cocoon code,
and (2) initialization Thread is not the same as thread making
request. It could be from different ThreadGroup, even.
Is that a problem?
Actual problem is that RunnableManager's threads should not be children of any
request processing thread, and currently this is the case because
RunnableManager is initialized eagerly.
If RunnableManager's thread pools are created lazily (==children of single
request processing thread), following can happen:
* All threads in pools inherit locals of the request thread,
which is wrong.
* All threads will be created in the ThreadGroup of the request
processing thread, will attempt to modify said group, and
can fail with SecurityException (you can create thread in a
thread group only if you have modifyThreadGroup priviledge).
* All threads will be limited to the priorities set for the
request processing thread's group priorities.
* All threads will inherit isDaemon, priority, contextClassLoader
attributes of the execution thread. Both setPriority and setDaemon
require permissions configured.
In short: request processing thread pool can be configured with different
priorities, different permissions than initialization thread. Loading
RunnableManager with lazy mode will hit these restrictions.
Hence my request to load RunnableManager eagerly to avoid any possible
complications.
Back to InheritableThreadLocals:
> So let's check the uses of InheritableThreadLocal. I found only 4 of
> them (what is your 5th?)
IDEA counted two mentions in SourceProtocolHandler, for one line - so yes it is
four actual variables.
Vadim
