Re: [Ekiga-devel-list] Code in lib/engine/components/opal/

[Julien Puydt <jpuydt free fr>]

Le 28/01/2013 10:24, Julien Puydt a écrit :
> The current memory handling is also unsatisfying (cf opal-main.cpp),
> since we put the endpoints in boost shared pointers, but with a
> null_deleter, which means we don't really manage them. This hits the
> current ekiga master : as Damien noted (in a private email), the
> endpoints get freed before the accounts, so the accounts call some
> endpoint and we get a crash! Somewhere else in ekiga, there must be some
> code which says to dispose of the endpoints ; that is wrong.
>
> The good solution is to remove that other code, and put our endpoints in
> the boost shared pointers with a deleter which will shut them down
> gently, then call delete. This way, we'll be sure that the endpoints
> will live as long as something in the ekiga needs them, and that they
> are properly closed whenever they're not needed anymore. It's the code
> which creates the objets, which should take care of disposing of the
> objects!

From what I saw in the opal headers:
- when we create an endpoint, it automatically gets registered to the 
call manager (and we can't prevent that) ;
- the call manager gets to clean the endpoints when it disappears (or 
when asked to remove it)

There doesn't seem to be anything to keep managers alive separately from 
the call manager, so the tree I proposed should perhaps become :

Opal::Bank -> Opal::Account -\
                              \
Opal::SIP::Dialect ------------> Opal::CallManager
                                       |
                                       v
                                 Opal::Sip::Endpoint


And everything I said about signals/orders/populate menu should go 
through the call manager. And we keep the null deleters.

Snark