Sylvain Wallez wrote: > > Carsten Ziegeler wrote: > > >Hi, > > > >there were some problems with multi-threading and the environment > >stack which should be fixed by last monday - at least that's > >what I thought. > > > >However, there is one subtle thing to keep in mind: > >ThreadLocal and InheritableThreadLocal variables! > >The current environment stack uses a InheritableThreadLocal > >variable - so you have to make sure that if you > >create/use a different thread that this InheritableThreadLocal > >variable is initialized correctly. > > > >Especially when you use thread-pools you have to > >manually set this variable (contained in the > >CocoonComponentManager) whenever you take a thread > >out of the pool and use it. > > > >Is it possible, that your problems are related to this? > > > > If the problem is related to some (Interited)ThreadLocals which haven't > the proper value, what about providing a ThreadPool component in Cocoon > that cleanly manages these values, so that applications requiring thread > do not have to wonder about it ? > Yes, I was thinking about this , too. So, go on: +1 :) But theoretically (turning panic mode on), this problem is much bigger: You have to know about each library (component) you use, if this component uses ThreadLocal variables and how they are used. Only if you know this, you can make a safe thread-pool implementation.
Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
