Re: [boost] Boost.Threads, N2178, N2184, et al

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
read/writes.

Regards,
                Stefan

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