[concurrency-interest] Target CPU utilization
joe.bowbeer at gmail.com
Thu Feb 15 19:27:46 EST 2007
The specifics depend on how your service is expected to be used. For
example, can it be invoked as-needed by a SwingWorker-style task? Or
does it churn away in the background?
Staying out of way of the GUI is especially important in the latter
case. Lowering the priority of your worker threads may be enough to
keep the GUI from dragging or sputtering.
If your service runs on-demand (and the user is essentially waiting
for you to finish), then providing prompt cancellation and periodic
progress reports is usually sufficient.
It looks like NetBeans and Eclipse have modes where a background task
can be foregrounded, and vice versa.
For the best integration (both in terms of UI and managing load), yes,
it can be important to leverage the platform's existing executors.
On 2/15/07, Peter Kovacs <peter.kovacs.1.0rc at gmail.com> wrote:
> How do I best integrate a library into an application context which is
> unknown beforehand (in terms of thread pools)? Do I have to share
> pools with the enclosing applications?
> For example assume our library is used in a GUI application which
> itself is built on the NetBeans platform. NetBeans has its own kind of
> thread pools: http://www.netbeans.org/download/dev/javadoc/org-openide-util/org/openide/util/RequestProcessor.Task.html.
> Does my library have to provide hooks where the application can have
> my libraries use the thread management of NetBeans?
> Or is the best approach "laisser fair, laisser aller"? And leave it to
> "the invisible hand" of the OS scheduler to arbitrate between the
> threads of coexisting thread pools?
More information about the Concurrency-interest