Boost logo

Boost :

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-03-26 19:52:09

Howard Hinnant wrote:

> My killer use case for the catchable cancel is a thread_pool library:
> Such a library would execute a small number of threads, and hold a
> queue of waiting tasks which get assigned to a thread when one is
> available. Clients of thread_pool can insert tasks into the queue,
> and when they do so they receive back a handle (which I'll call
> future) through which they can join with, or cancel, the inserted task.
> If the client decides to cancel the task, this translates into an
> exception being thrown in the running thread. Up in the start function
> which wraps/adapts the user-supplied function, that exception is
> caught, and the still running thread is returned to idle status in the
> thread_pool, ready to accept another task from the pool's queue.

Aha ! That's where the vocabularies clash ! :-)

Canceling a task isn't the same as canceling a thread. A thread
is an OS entity, while the task is a user-space entity.

While I can definitely see the request to be able to abort a task
while reusing the thread, I don't think it makes sense to request
the thread to be aborted and then let it decide to silently live
on (thread-reuse could still be implemented internally, of course,
without the user having to care).

So, your request to be able to cancel a task is one thing, but,
one can argue, this doesn't have anything to do with a threading
facility / API. In fact, if you want an interruptible I/O, you
may as well use async I/O (i.e. use select / poll and non-blocking


      ...ich hab' noch einen Koffer in Berlin...

Boost list run by bdawes at, gregod at, cpdaniel at, john at