----- Original Message -----
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
Subject: RE: Latest diffs, source code
> We'd have to replace the DefaultThreadManager block. My concern is that
> without auditing the code, I don't know, a priori, that we wouldn't
> introduce new problems by mixing and matching between util.concurrent and
> Excalibur. Avalon is already planning a JSR 166 pickup, and James is
> currrently running OK with their code.
true...
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. Was a bit allured by the close match.
>
> > > finally {
> > > Thread.currentThread().interrupted();
> > > }
>
> > Would this be needed post threading fixes in Avalon ?
>
> Probably not, but why not clean up after ourselves?
Seems harmless unless some code is checking for Thread#isInterrupted. That
does not seem likely as Thread#interruped is in finally clause. Is that
right ?
One question: Why should Thread#interrupt ever be called other than at
system shutdown time ? Is there a piece of code that calls Thread#interrupt
other than at system shutdown ? Looked some but could not find a specific
place wondering if you knew...
> If we did replace the
> ThreadPool implementation, what requirements might it have? This is a
good
> issue tidbit to raise with the JSR 166 folks. There ought to be a defined
> semantic for working with thread pools. Either Runnables have to catch
> exceptions and clean up, or they don't. For example, Commons ThreadPool
(in
> their sandbox) says that "inside the run() method of your Runnable object
> you must handle Exceptions properly." The docs don't mention other thread
> state issues.
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.
Harmeet
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
