Re: [boost] [thread] 2 questions about thread interruption

Le 18/04/2016 23:50, Andrzej Krzemienski a écrit :

2016-04-18 23:42 GMT+02:00 Andrzej Krzemienski :

...

Hi, I have two questions connected to thread interruption in Boost.Thread.

*1.* The docs say that interrupt_and_join_if_joinable is defined as follows:

``` struct interrupt_and_join_if_joinable{

void operator()(thread& t) { t.interrupt(); if (t.joinable()) { t.join(); } }};

```

Sorry, let me continue with the question. Is there a reason why t.interrupt() is called without checking if t is joinable? This looks uncomfortable to me that I would be potentially calling interrupt() on a not-a-thread. Interrupting a not-a-thread should do nothing. I will add this to the reference documentation. However nothing prevents to implement it this way

void operator()(thread& t) { if (t.joinable()) { t.interrupt(); t.join(); } }}; I will do it.

*2.* When I make a call to this_thread::wait_for(),

blocking for a long time in thread t2, and the instant later I call t2.interrupt() from another thread t1. Do I have to wait the long time until wait_for() stops blocking t2, or does thread_interrupted get called 'immediately' after interrupt() is called from t1? It depends. If sleep_for is implemented using nanosleep()/pthread_delay_np() there is no way to throw the

Do you mean sleep_for here? thread_interrupted exception. However, if it is implemented waiting on a condition variable wait_for, then the exception will be throw before the duration elapses. Currently, sleep_for make use of nanosleep/pthread_delay_np when available. The advantage been that the sleep is steady/monotonic.

*3.* Does the support for interruption points require the other synchronization operations (like locks on mutexes) to be slower (in order to monitor interruption requests)? Not for locks and mutex, but yes it will be a little bit slower for condition variables, as we need to store the condition variable on which a thread could be waiting for.

I've on my TODO list a task to build interuptible threads on top of raw threads, but this will need to have also specific condition variables :( Best, Vicente