-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of k-oli@gmx.de Sent: Wednesday, June 11, 2008 10:21 PM To: boost@lists.boost.org Subject: [boost] interrest in a thread-pool library
Hi, I follow the discussion about boost.future since the review request
Braddock. I'm using Braddocks future implementation for my threadpool library - may you are interessted in (I've uploaded two versions in the boost vault/Concurrent Programming).
The library provides:
- thread creation policies: determines the managemnt of worker threads - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time
- channel policies: manages access to queued tasks - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited numer of queued tasks - rendezvous syncron hand-over between producer and consumer
How would you say your thread-pool libraries compare with Philipp Henkel's threadpool library [<http://threadpool.sourceforge.net/>]? Moshe form threads
- queueing policy: determines how tasks will be removed from channel - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one)
- tasks can be chained and lazy submit of taks is also supported
(thanks
to Braddocks future library).
I've uploaded two versions.
In version 1 a future is returned by submit of a task. Canceling the future means removing the task form the channel if it is still pending.
Version 2 returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> this_thread::interruption_point() ).
Oliver _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost