I would like to ask around about a strategy on how to tacke the following threading problem:

I am maintaining a boost intensive portable C++ client-server application and recently have included a highly complex 3rd party algorithm into my application that does CPU intense stuff. Long running stuff. Often in the range of days. While at the same time being heavy in OpenMP usage. Now of course requirements are that the user has to be able to cancel this.

The algorithm runs in a boost threads controlled background thread. Now I began to place interruption points throughout the 3rd party code but soon had to realize that a lot of CPU time is being handled in OpenMP threaded code regions.

So the question is: How can I more or less gracefully shut this down? How do interruption points work in an omp parallel for loop? Do I have a chance at all?

My constraints here are a bit forgiving. Given the complexity of the 3rd party code I have already accepted the notion that this is gonna be a memleak monster. Luckily, there's no disk or other hardware access so I'm ready to live with a certain amount of mem not being cleaned up. Yet the backend thread communicates with the spawning class by calling a mutexed callback when it's ready so the user knows it's cancelled. This is protected by a boost mutex as well. And juding from the horrible threading "clogs" that I observed in my first trials I suppose this is gonna be a problem as well.

And input is appreciated. And yes, I am aware that this is gonna be an ugly mess.

Cheers,

Stephan