cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: CommandManager issues [was Re: Releasing 2.1.1?]
Date Tue, 02 Sep 2003 18:26:20 GMT
Bruno Dumon wrote:

> I don't want to spend very much time on this thread anymore, but here's
> the short summary:

Understandable.  Again, I do want to fix the issues.  Also note that it is
accessible to Cocoon committers.

> I don't have any problem with the concepts behind the
> CommandManager/ThreadManager or the event package in general, in fact I
> think they're very good. My last point about the continuous checking of
> events every 100 ms isn't really a big issue for me.

I was catching up over the weekend.

> I only wanted to point out some problems in the current implementation
> as it is. Those problems can of course be fixed, and for Cocoon to
> depend on this system, they also need to be fixed. And maybe I'm also
> wrong on some of these problems.

Some of them I think are misconceptions.

> One of these problems is the above mentioned fact that all events from
> one CommandManager are executed on one thread, no matter how many
> threads you configure in the ThreadManager. I got this only from looking
> at the code, here's the explanation I mentioned earlier in this same
> thread, I hope you can prove me wrong:

This is one of the misconceptions.  More info below.

> If you look at the code of the AbstractThreadManager:
> In the method "register( EventPipeline pipeline )" one PipelineRunner is
> created to handle events from the given EventPipeline (e.g. the one of
> the CommandManager).
> Then in the run() method the PipelineRunners are executed in parallel by
> using the PooledExecutor: m_executor.execute( nextRunner );
> But in the method, and the
> CommandManager.handleEvents() which is called by it, no new threads are
> started.

The PooledExecutor has a group of threads associated with it.  In fact the
executor is what creates/reuses/manages the threads.  The CommandManager
does not have to create the threads itself.  If you set the THreadManager
(which manages the threads in the PooledExecutor) to use a certain number
of threads, it will use them all.  You are never limited to only one thread.
I usually keep two worker threads per processor working all the time.

There is now also a new ThreadManager that has a thread pool (PooledExecutor)
per PipelineRunner that is registered.  I don't recommend its use just yet
because it hasn't been tested fully.  However, the CommandManager will use
as many threads as the ThreadManager will allow.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

View raw message