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 PipelineRunner.run() 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



Reply via email to