> By looking at the code it looked like James is using only execute
signature
> on ThreadPool and this matches very well with PooledExecutor#execute
method
> in util.concurrent.
Yes, but they actually work very differently. It appears to me that we'd
have run into other issues if we were using util.concurrent. For example,
since PooledExecutor's workers don't clear the interrupted state, if a
Runnable checked that state at the top of an internal loop, it would
immediately exit. Second, PooledExecutor takes an interesting approach to
thread pooling, and does not actually do any pooling unless there is a
backlog of tasks. This would have had the effect of masking the interrupted
state issue until we ran at a heavy load factor. I'd have to write some
tests, but that appears to be the case from reading the code.
> Seems harmless unless some code is checking for Thread#isInterrupted.
> That does not seem likely as Thread#interruped is in finally clause.
The purpose of the finally clause is so that when James is done with the
thread, we give it back to the thread pool in a pristine state. It is the
last thing that the handler does, so presumably any of our code that cared
about the interrupted state is already finished with it.
> Why should Thread#interrupt ever be called other than at system
> shutdown time?
For the usual reasons of calling Thread#interrupt. At one point, Peter was
calling it in a version of his Watchdog trigger. When we switch to
java.nio, you would call it rather than the somewhat ruder mechanism of just
closing the socket.
> To me desired state for reuse should be default state. State should be
reset
> by pool after use. However there does not seem to be happening either in
my
> snapshot of Avalon or util.concurrent. It almost seems that plugin code
into
> a thread pool is not expected or should not alter thread state.
This is why we added the finally clause to reset the state. And why I
commented that the JSR 166 group should document normative behavior.
--- Noel
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
