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 read/writes. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...