commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John McNally <jmcna...@collab.net>
Subject [pool] swallowing InterruptedException
Date Thu, 17 Jul 2003 21:36:17 GMT
I see in classes like GenericObjectPool the following:

} catch(InterruptedException e) {
    // ignored
}

which will result in a thread that has been interrupted potentially
returning back to a waiting state.  I just want to be sure that this is
done for a good reason, so it would be nice to have more of a comment
than just // ignored.  Why is it appropriate in the case of an object
pool to ignore calls to Thread.interrupt(), except possibly to use it as
a wake up mechanism?

It seems possible that an application using commons-pool could have some
criteria for abandoning an attempt to get an object from the pool that
is not a simple timeout criteria.  If commons-pool did not ignore calls
to Thread.interrupt() the application would have some way to execute on
this hypothetical criteria.

What were the decisions for the present design?

john mcnally




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message