[asterisk-dev] invasive fixes to chan_iax2 in 1.4

[BJ Weschke]

 +1 from my point of view. While this is new "core functionality" I
think it's necessary to fix bugs that wouldn't otherwise be fixed.

On 8/17/07, Russell Bryant <russell at digium.com> wrote:
> Greetings,
>
> I have a branch where I have fixed some bugs in chan_iax2.  The code is intended
> to go in both 1.4 and trunk.  The changes are rather invasive, so I wanted to
> describe the changes and justify them before merging them in.
>
> svn diff http://svn.digium.com/svn/asterisk/branches/1.4/channels/chan_iax2.c
> http://svn.digium.com/svn/asterisk/team/russell/iax_refcount/channels/chan_iax2.c
>
> This branch is targeted at fixing a set of crashes.  They were brought to my
> immediate attention by being given access to a system that could be easily
> crashed by issuing a reload while running a registration load test.
>
> The problems turned out to be related to the handling of iax2_peer objects.
> However, the handling of iax2_user objects suffers from the same problems so the
> same changes have been made to them, as well.  There are various situations
> where peers could get destroyed while other threads still hold references to them.
>
> To fix this problem, I made it so the objects are reference counted.  To do
> this, I had 3 choices.
>
> 1) Don't use any object model.  Just write it in "manually".  This felt like the
> worst choice.  It's best to use a common implementation when possible.
>
> 2) Use astobj.h.  This hasn't made it very far throughout the code base.  The
> API is a set of macros which are cumbersome to use, and especially to debug, in
> my opinion.  However, it's certainly better than option #1, as it is a common
> implementation already in use in some places.  However, it is likely that this
> is going to be deprecated in favor of astobj2.
>
> 3) Use astobj2.  Luigi Rizzo and one of his students, Marta Carbone, have
> written a new reference counted object model and have had it in a branch for a
> long time now.  After reviewing astobj versus astobj2, I perferred astobj2, and
> decided to go with that.  It doesn't use macros, and is still more efficient.
>
> Another reason that I chose to go with astobj2 was that I *know* this is not the
> end of problems of this type.  In fact, there is a nice set of crashes on the
> bug tracker which the fix will be converting the ast_channel struct over to a
> reference counted object model, which is going to be a big job.  Since we are
> likely going to have to do more conversions of object handling to this method, I
> figured it was worth bringing in astobj2 to 1.4 so that we can use it as needed,
> and not do all of this work using a model that we know will be deprecated in the
> near future.
>
> If you have any comments or objections, I would like to hear them.  Also, feel
> free to ask for any clarification or more detailed explanations of the things I
> have mentioned here.
>
> If there are no objections, I will be merging these changes into 1.4 next week.
>
> --
> Russell Bryant
> Software Engineer
> Digium, Inc.
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>


-- 
Bird's The Word Technologies, Inc.
http://www.btwtech.com/