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

Subject: Re: [Boost-users] Using Boost.Thread with lowlevel system software: async interruption question
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-09-02 15:04:14

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