Le 02/09/13 10:30, Nikita V. Youshchenko a écrit :

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.

Hi, the section [1] describes the services Boost.Thread provides. However I don't think it is enough, adding some |boost::this_thread::interruption_point()| calls would not be enough. You can always extract the native_handle and use the pthread primitives you need. Best, Vicente