[Boost-users] Using Boost.Thread with lowlevel system software: async interruption question

Subject: [Boost-users] Using Boost.Thread with lowlevel system software: async interruption question
From: Nikita V. Youshchenko (yoush_at_[hidden])
Date: 2013-09-02 04:30:38

Hi

I'm developing lowevel system software, that runs under linux and 
communicates with custom linux drivers for custom hardware.

I'm evaluating possibility to switch from explicit use of pthread interface 
to Boost.Thread.

After reading documentation, I can't understand if there is any solution 
for async thread interruption with Boost.Thread. 

First use case is - need to interrupt thread that is sleeping in custom 
dirver's ioctl() call. Drivers are well-written, in terms that any sleep 
inside ioctl()s is immediately interrupted on signal arrival. This 
perfectly couples with pthreads' PTHREAD_CANCEL_ASYNCHRONOUS cancellation 
type - which is based on signals. Thus, to make threads cancellable while 
sleeping inside ioctl(), it is enough to set cancellation type to 
PTHREAD_CANCEL_ASYNCHRONOUS before entering system call.

Second use case is - need to interrupt thread that is running 3rd party 
legacy code. The only method I know to physically communicate termination 
request to thread running unaware code is signal. Again, this couples well 
with PTHREAD_CANCEL_ASYNCHRONOUS.

Is it possible to solve these two use cases with Boost.Thread?
Per Boost.Thread documentation, thread interrupts only in predefined 
interruption points. Which is similar to pthreads' 
PTHREAD_CANCEL_DEFERRED, and is not what I'm looking for.

I imagine I could play with signal handler that does longjump() to some 
point where I manually raise boost::thread_interrupted exception. Will 
that work? Sure this will loose any destructor calls for objects created 
in call stack "below setjmp point" - but in first use case I can ensure 
that no cleanup below setjmp is required, and in second use case this 
looks unavoidable...

Any better ideas?

I do not have any portability needs in this software - drivers are 
linux-only anyway. So linux-only solution is perfectly ok.

Nikita Yushchenko