Hi I am currently evaluating the task library currently in the vault for production use. The library is very well thought in my opinion, thank you very much Oliver for providing it to the community. It seems it was scheduled for review before but now it isn't. Vicente was the review manager. Is the library still intended to be reviewed? Is there some active work in the library? What about other libraries task depends on? The bound queues used in thread pools always causes the thread submitting task to wait if the queue is full. In our use cases, we need to fail the queuing, rather than wait. Is there any interest in adding this functionality to the library? In case there is I could perform the programming and testing. Thank you again. Cheers Jorge
Am 24.02.2011 19:01, schrieb Jorge Lodos Vigil:
Hi I am currently evaluating the task library currently in the vault for production use. The library is very well thought in my opinion, thank you very much Oliver for providing it to the community. It seems it was scheduled for review before but now it isn't. Vicente was the review manager. Is the library still intended to be reviewed? Is there some active work in the library? What about other libraries task depends on? The bound queues used in thread pools always causes the thread submitting task to wait if the queue is full. In our use cases, we need to fail the queuing, rather than wait. Is there any interest in adding this functionality to the library? In case there is I could perform the programming and testing. Thank you again.
Cheers Jorge
Hello Jorge, boost.task depends on boost.tasklet (which I'm currently re-factoring) and boost.context (review begins March 21, 2011). The task-library needs a re-factoring too which I'll start after boost.tasklet is finished and boost.context is accepted by the community. Ron requested to remove boost.task from the schedule list because of the re-factoring - I'll ask for review later. You can solve your problem related to bounded-queue by useing the unbounded-queue in order to queue tasks as much as you want (no blocking). Oliver
On 2011/2/24 Oliver wrote:
Am 24.02.2011 19:01, schrieb Jorge Lodos Vigil:
The bound queues used in thread pools always causes the thread submitting task to wait if the queue is full. In our use cases, we need to fail the queuing, rather than wait. Is there any interest in adding this functionality to the library? In case there is I could perform the programming and testing.
You can solve your problem related to bounded-queue by useing the unbounded-queue in order to queue tasks as much as you want (no blocking).
Thank you Oliver, but what I need is a thread pool with a limited queue and non-blocking task submission mechanism. The queue size may be changed at runtime, but there is always a maximum. If the queue is full, the submission must fail instead of waiting. I had not seen tasklet library before, I see now the refactoring you are talking about. Please consider adding a bounded non-blocking queue for using with the thread pool. If you need anything I'll be glad to help. I'll probably use the current task library version anyway. Thanks again. Cheers Jorge
participants (2)
-
Jorge Lodos Vigil -
Oliver Kowalke