[asterisk-dev] Fwd: [asterisk-commits] mjordan: branch 12 r426995 - /branches/12/res/res_stasis.c

Matthew Jordan mjordan at digium.com
Mon Nov 3 09:02:56 CST 2014


On Sun, Nov 2, 2014 at 3:29 PM, Matthew Jordan <mjordan at digium.com> wrote:
> On Sun, Nov 2, 2014 at 1:27 AM, Corey Farrell <git at cfware.com> wrote:
>> If it's possible for apps_registry to be NULL then it's possible for the
>> condition to race.  Maybe we need to use AO2_GLOBAL_OBJ_STATIC?  Could this
>> issue apply to the other global containers in this module (app_controls,
>> app_bridges, app_bridges_moh, app_bridges_playback)?
>>
>
> I haven't been able to trigger a crash with anything else. I'm
> hesitant to pull out AO2_GLOBAL_OBJ_STATIC, simply because it adds a
> reasonable chunk of overhead on a container that should never be NULL
> unless you are in the middle of an unload operation.
>

I thought about this some more this weekend, and I think you're
actually right. Really, all of the global containers here should be
protected in some fashion by an AO2_GLOBAL_OBJ_STATIC.

There is another option however. All of the interactions with these
containers are really occurring due to an external request coming in
asking for some manipulation. Technically, there's no reason for the
HTTP server to allow those requests - if Asterisk is shutting down,
there's no real reason to service the requests. The HTTP server could
be modified to start rejecting requests with some 5xx error code -
which would also prevent this situation from occurring.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org



More information about the asterisk-dev mailing list