ThreadPool queue

Can someone explain me better something about ThreadPool.queue()?
For example:

private function queueExplanation() {
    var _theadP:ThreadPool = new ThreadPool(1,1);
    for (i in 0...10000) {
             function () {

Which of two _threadP.queue() is correct?
What queue() represent exactly, start of queue or something else?

In my experience put queue(); inside a for cicle seems repeat all works added many times. It is correct?

Thanks, David.

Oh, I think you have this flipped. Usually you would something like this:

var pool = new ThreadPool (0, 5);
pool.doWork.add (function (x) {
    // do some expensive math calculation to find y
    pool.sendComplete ({ x: x, y: y });
pool.onComplete.add (function (result) {
    trace (result.x + " calculates to a y of " + result.y);
pool.queue (100);
pool.queue (200);
pool.queue (300);

A ThreadPool is ideal when you can use the same worker method over multiple incoming objects or values, or if you want to be able to pool multiple threads doing the same thing.

The BackgroundWorker object is designed for a one-off task

var worker = new BackgroundWorker ();
worker.doWork.add (function (value) {
    worker.sendComplete (value + 100);
worker.onComplete.add (function (result) {
    trace (result);
}); (50);

For a quick background thread (for thread-safe code) you can also use a new Future with the async flag

var future = new Future (function () { return 100 + 100; }, true);
future.onComplete (function (value) {
    trace (value);
1 Like

Thanks for reply but I really need to understand more with a specific case and a specific issue.
I need to queue about 100 saving operations of images, also big images depending from device resolution, without consuming all FPS available (launching many workers to do that can really use 100% of CPU). I think to use a ThreadPool to limit number of available threads. Number of Thread set to 1 is only a way to limit usable threads, I think in real code I can instance 2 threads.

Using my example with queue() outside the for seems works perfectly. Is that an unfair use of ThreadPool?

Thanks Again,

I wouldn’t add much in the way of doWork listeners. Here’s another example:

var threadPool = new ThreadPool (0, 1);
threadPool.doWork.add (function (path) {
    var asset = loadAsset (path);
    threadPool.sendComplete ({ path: path, asset: asset });
threadPool.onComplete.add (function (result) {
    trace ("loaded asset " + result.path + ": " + result.asset);
threadPool.queue ("image1.png");
threadPool.queue ("image2.png");

Ok thanks a lot for your time :slight_smile:

In a case like this, where you might indeed have “thousands of things to do,” I would take a different conceptual approach:   define one dedicated thread to perform each task repeatedly.   (Or, give a thread-pool worker a single piece of work that iterates through a long series of activities, one after the other, without stopping.)   Most of the time, there will turn out to be some shared data-structure that requires locking to protect it … and if so, there goes any real advantage of using a pool!   Whereas if you know that one and only one thread is actually performing a particular type of work, no locking semantics are required at all.