discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] usrp2 dtor can throw !


From: Gaetano Mendola
Subject: Re: [Discuss-gnuradio] usrp2 dtor can throw !
Date: Sat, 15 Jan 2011 23:51:13 +0100

On Sat, Jan 15, 2011 at 8:34 PM, Josh Blum <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]