On Wed, 12 Dec 2001 07:21, Berin Loritsch wrote: > (Simple ThreadPerProcessor Manager) > 1) ThreadManager has a background thread for each processor to manage all > the Stages. 2) When a Stage is registered with the ThreadManager, the > background thread tells the stage to handle it's events (if any).
This is the standard method and really isn't a ThreadPool or anything like that (for it only has one thread and it never shutsdown). > (ThreadPoolPerSourcePerStage Manager) I believe this is only needed when you are dealing with resources that are blocking. And even then it is just used to "fake" non-blocking IO. > The difference is that The Avalon ThreadPool is designed for a pool of > threads doing disparate things--as opposed to a pool of threads doing the > *same* thing. I can't see that it makes any difference. > There are strengths to both approaches, and I wanted to get a feel for what > was more common. For instance, I can see having a maintenance task running > in the background for the duration of the runtime. In this case, the SEDA > approach is better because it allows the number of maintenance threads to > grow with the demand on the system (up to a threshold). In other words, > all maintenance is performed in the same thread, and all events handled in > the same thread. As that thread gets behind in processing the events in > the queue, the ThreadController adds another thread. Again - that is not impossible in Avalons existing ThreadPool impl as it blocks till a thread is available. > What is the feeling regarding ThreadManager/ThreadController/ThreadPool > vs. ThreadPool/ThreadControl? ThreadPool/ThreadControl could be used to implement ThreadManager/ThreadController/ThreadPool if the needs arises. However as java as non-blocking IO as of jdk1.4, the importance of such things in a SEDA style architecture becomes lesser because most resources are available in non-blocking format. -- Cheers, Pete ----------------------------------------------- "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -Albert Einstein ----------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
