Now I see what you mean. :) What you say makes a lot of sense. I applied the same change to UnorderedThreadPoolExecutor
Cheers, Trustin On Nov 10, 2007 12:35 PM, Mike Heath <[EMAIL PROTECTED]> wrote: > Trustin Lee wrote: > > corePoolSize is a configuration property that represent the minimum > > size of the pool. So, I think updating corePoolSize property doesn't > > make sense. Am I missing something? > > With my suggestion, OrderedThreadPoolExecutor would only change > corePoolSize if corePoolSize > maximumCorePoolSize. I just updated and > noticed that you added a check that throws an IllegalArgumentException > if maximumPoolSize < corePoolSize which is exactly what > ThreadPoolExecutor does. I don't have a problem with this approach. > (Besides, who am I to argue with Doug Lea?) > > On the flip side, it makes sense in my mind to not allow the > corePoolSize to exceed the maximumPoolSize. TheadPoolExecutor doesn't > check for this but I don't see why it shouldn't. I added this check to > OrderedThreadPoolExecutor.setCorePoolSize > > This is just me being picky but setMaximumPoolSize should also only call > removeWorker if workers.size() > maximumPoolSize. So, if my > maximumPoolSize is 100 and I change it to 50 and I only have 5 worker > threads, it doesn't call removeWorker() 50 times (which wouldn't really > matter since removeWorker() won't actually do anything in this case). I > changed that too. > > This is the part where you say, "Look, setMaximumPoolSize and > setCorePoolSize will probably never even get used. Mike, stop being > such a pedant and go find something productive to do." > > -Mike > -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
