Question: Thread A executes a blocking call in a loop, until Thread B signals it to continue with the rest of the execution.

I tried the classic approach of an signal handler, which will change a condition variable, so I can test the condition before the the next call starts.

The problem now arises in the case, when the signal arrives after the check of the condition, but before the blocking call. 

Short pseudo code example of the problem:

```
while(!isInterrupted){
  raise(SIGINT)
  block()
}  

```

Assuming I cannot access or change the implementation of the blocking code and the blocking call doesn't provide an internal timeout functionality, which the signal handler could set to the minimal value, what would be the correct way for C and C++ to handle this?

Signals are used as the blocking call may only be woken up by receiving a SIGINT.

Thank you in advance for your help.

Answer: 
If you can modify the calling assemblies of your libc like I have with <https://github.com/pskocik/musl>, then you can eliminate this [time-of-check to time-of-use problem](https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use) by having your signal handler call a special function (provided in the modified libc) that'll break the system call if the signal is received while your code is in the function call wrapper after the check but not in kernel mode yet (in kernel mode, blocking calls are naturally broken by signal deliveries naturally).

Without access to your libc (/ you're building purely on top of POSIX), I believe the best you can do is a protocol-based solution:

* setup a mechanism by which signal receivers acknowledge signal receipts
* have the signal-sending code repeat (preferably with some sleeping) until receipt is acknowledged

That might not be the easiest to set up though (essentially, you'd be fighting POSIX to a degree). If you can afford it, doing the blocking operation in a new thread should be simpler, and `pthread_cancel`, unlike `pthread_kill`, should be able to reliably elicit a response (in this case, complete thread cancellation) in the target, unlike `pthread_kill`.

The downside of using a separate thread is it will be a bit more resource hungry.
Please look at mutexes and condition variables for this.