[asterisk-dev] [Code Review] 2540: Fix shutdown assertions in stasis-core

[Mark Michelson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2540/#review8641
-----------------------------------------------------------

Ship it!


Only problems I found were in docs. Ship it!


/trunk/include/asterisk/stasis.h
<https://reviewboard.asterisk.org/r/2540/#comment16895>

    s/your must/you must/



/trunk/include/asterisk/stasis.h
<https://reviewboard.asterisk.org/r/2540/#comment16896>

    s/procedes/proceeds/



/trunk/include/asterisk/stasis_message_router.h
<https://reviewboard.asterisk.org/r/2540/#comment16897>

    either
    
    s/messages has/messages have/
    or
    s/messages has/message has/


- Mark Michelson


On May 14, 2013, 9:23 p.m., David Lee wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2540/
> -----------------------------------------------------------
> 
> (Updated May 14, 2013, 9:23 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan and opticron.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> In r388005, macros were introduced to consistently define message
> types. This added an assert if a message type was used either before
> it was initialized or after it had been cleaned up. It turns out that
> this assertion fires during shutdown.
> 
> This actually exposed a hidden shutdown ordering problem. Since
> unsubscribing is asynchronous, it's possible that the message types
> used by the subscription could be freed before the final message of
> the subscription was processed.
> 
> This patch adds stasis_subscription_join(), which blocks until the
> last message has been processed by the subscription. Since joining was
> most commonly done right after an unsubscribe, a
> stasis_unsubscribe_and_join() convenience function was also added.
> 
> Similar functions were also added to the stasis_caching_topic and
> stasis_message_router, since they wrap subscriptions and have similar
> problems.
> 
> Other code in trunk was refactored to join() where appropriate, or at
> least verify that the subscription was complete before being
> destroyed.
> 
> Review: https://reviewboard.asterisk.org/r/2540
> 
> 
> Diffs
> -----
> 
>   /trunk/main/devicestate.c 388689 
>   /trunk/main/app.c 388689 
>   /trunk/include/asterisk/stasis_message_router.h 388689 
>   /trunk/include/asterisk/stasis.h 388689 
>   /trunk/channels/chan_sip.c 388689 
>   /trunk/funcs/func_presencestate.c 388689 
>   /trunk/channels/chan_iax2.c 388689 
>   /trunk/apps/app_voicemail.c 388689 
>   /trunk/apps/app_queue.c 388689 
>   /trunk/main/endpoints.c 388689 
>   /trunk/main/manager.c 388689 
>   /trunk/main/manager_channels.c 388689 
>   /trunk/main/pbx.c 388689 
>   /trunk/main/stasis.c 388689 
>   /trunk/main/stasis_cache.c 388689 
>   /trunk/main/stasis_channels.c 388689 
>   /trunk/main/stasis_endpoints.c 388689 
>   /trunk/main/stasis_message_router.c 388689 
>   /trunk/res/res_chan_stats.c 388689 
>   /trunk/res/res_jabber.c 388689 
>   /trunk/res/res_stasis.c 388689 
> 
> Diff: https://reviewboard.asterisk.org/r/2540/diff/
> 
> 
> Testing
> -------
> 
> Ran unit tests; core stop now and core stop gracefully.
> 
> 
> Thanks,
> 
> David Lee
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130516/bd190b0d/attachment.htm>