[Asterisk-code-review] stasis_state: Add new stasis_state module (...asterisk[master])

[Kevin Harwell]

Hello Friendly Automation, Joshua Colp, 

I'd like you to reexamine a change. Please visit

    https://gerrit.asterisk.org/c/asterisk/+/11462

to look at the new patch set (#2).

Change subject: stasis_state: Add new stasis_state module
......................................................................

stasis_state: Add new stasis_state module

This new module describes an API that can be thought of as a combination of
stasis topic pools, and caching. Except, hopefully done in a more efficient
and less memory "leaky" manner.

The API defines methods, and data structures for managing, and tracking
published message state through stasis. By adding a subscriber or publisher,
consumers can more easily track the lifetime of the contained state. For
instance, when no more publishers and/or subscribers have need of the topic,
and associated state its data is removed from the managed container.

* stasis_state_manager *

The manager stores and well, manages state data. Each state is an association
of a unique stasis topic, and the last known published stasis message on that
topic. There is only ever one managed state object per topic. For each topic
all messages are forwarded to an "all" topic also maintained by the manager.

* stasis_state_subscriber *

Topic and state can be created, or referenced within the manager by adding a
stasis_state_subscriber. When adding a subscriber if no state currently exists
new managed state is immediately created. If managed state already exists then
a new subscriber is created referencing that state. The managed state is
guaranteed to live throughout the subscriber's lifetime. State is only removed
from the manager when no other entities require it.

* stasis_state_publisher *

Topic and state can be created, or referenced within the manager by also adding
a stasis_state_publisher. When adding a publisher if no state currently exists
new managed state is created. If managed state already exists then a new
publisher is created referencing that state. The managed state is guaranteed to
live throughout the publisher's lifetime. State is only removed from the
manager when no other entities require it.

* stasis_state_observer *

Some modules may wish to watch for, and react to managed state events. By
registering a state observer, and implementing handlers for the desired
callbacks those modules can do so.

* other *

Callbacks also exist that allow consumers to iterate over all, or some of the
managed state.

ASTERISK-28442

Change-Id: I7a4a06685a96e511da9f5bd23f9601642d7bd8e5
---
A include/asterisk/stasis_state.h
A main/stasis_state.c
A tests/test_stasis_state.c
3 files changed, 1,774 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/62/11462/2
-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/11462
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-Change-Id: I7a4a06685a96e511da9f5bd23f9601642d7bd8e5
Gerrit-Change-Number: 11462
Gerrit-PatchSet: 2
Gerrit-Owner: Kevin Harwell <kharwell at digium.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>
Gerrit-Reviewer: Kevin Harwell <kharwell at digium.com>
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20190625/a45e82db/attachment.html>