Hello Chris
Le 05/10/12 00:10, Mattmann, Chris A (388J) a écrit :
Thanks for taking care of this work and I saw the Threads classes you've
been working on. I have a question -- how do these relate to the
java.util.concurrent
packages -- are those incompatible with OSGI giving us a need to construct our
own
such classes in SIS, or are the classes you are committing complementary and/or
orthogonal to java.util.concurrent?
java.util.concurrent is not incompatible with OSGi as far as I know.
Actually I use and like this package, but the DaemonThread committed
yesterday is for a different purpose.
java.util.concurrent provides Executors which receive tasks, pick some
available threads in a ThreadPool (creating new ones if needed), uses
the thread for executing the task until completion, then give back the
thread to the ThreadPool. The new fork-join framework in JDK7 goes on
step further by transferring some piece of work from one thread to an
other. Each task uses a thread for a limited amount of time.
The class that I committed is a single daemon thread living for the
whole application lifetime. There is no ThreadPool. The thread is
dedicated to a single job: to watch a ReferenceQueue for doing cleaning
work when some objects are garbage collected. We do not submit tasks
ourselves; on the contrary, we wait for tasks to come from the garbage
collector. So this is the opposite of a java.util.concurrent.Executor :)
I plan to use java.util.concurrent for tasks that are more computational
(I already do in Geotk).
Thanks for your feedback,
Martin
