On Sat, Jan 15, 2011 at 8:34 PM, Josh Blum <j...@joshknows.com> wrote: > I dont think that this is an issue. Are you actually seeing exceptions > thrown at deconstruction time?
It is a very issue because it was for us and I digged this due to our application experiencing crash. > There is nothing that would cause the dtor to get interrupted AFAIK. The > only way this would be an issue is when thread "A" calls interrupt() on > thread "B" when "B" is blocking in the join_all call within the > usrp2::impl::~impl(). Which could happen if you had a usrp2::impl sptr > count reset to 0 at the exit of thread "B". Consider this code snipset: boost::thread::operator()() { usrp2::usrp2::sptr myDevice = usrp2::usrp2::make(....) .... boost::thread::sleep(....) } if a boost thread running that code gets an interrupt while sleeping, it throws an exception (boost::thread_interrupted) due the fact that sleep is an interruption point for boost. At this point the stack unwinding starts the destruction of the smartpointer myDevice calling then the destructor of usrp2::usrp2::impl performing a thread_group::join_all (another interruption point), at this point if the thread gets another interrupt the thread_group::join_all throws another exception while a stack unwinding is already going on => program aborts. To rub salt into wound consider that boost (I believe corrected only on 1.45) was affected by the bug #2330 and thread under some circumstances just ignore interrupt (even if passing from an interruption point), so some application (like our one) in order to be sure to not stuck for ever on a join after an interrupt does instead a timed_join and reissuing the interrupt in case the join times out. > In any case, putting a boost::this_thread::disable_interruption at the > first line of the dtor wouldnt hurt to do. :-) I would suggest a try catch instead for two reasons, first of all a DTOR should not throw ever (even next c++ standard has the requirement to check at compile time of a DTOR can throw) and disable interruption can have as effect a delay in the thread exiting if the thread_group::join all inside the usrp2::impl::stop_bg() doesn't terminate quick enough (or may be never). Regards Gaetano Mendola -- cpp-today.blogspot.com _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio