asterisk

Commit Graph

Author	SHA1	Message	Date
Alexander Traud	6988386234	stasis: Fix for Doxygen. ASTERISK-29750 Change-Id: Iea50173e785b2e9d49bc24c0af7111cfd96d44a9	4 years ago
Corey Farrell	f7045cefd9	stasis_state: Create internal stasis_state_proxy object. This improves the way which stasis_state reference counting works. Since manager->states holds onto the proxy object instead of the real object this allows stasis_state objects to be freed when appropriate without use of a special state_remove function. Additionally each distinct eid associated with the state holds a reference to the state to prevent early release and potentially allow easier debug of leaks. Change-Id: I400e0db4b9afa3d5cb4ac7dad60907897e73f9a9	6 years ago
Corey Farrell	3dfbc05c53	stasis: Fix leaks * Release reference returned by cache_remove * state_alloc unconditionally bumped state_topic even when it was locally allocated. Change-Id: I51101bf7d07b8dc8ce8fc46b6cb31fbbd213fbc7	6 years ago
Kevin Harwell	83c6ebbae8	stasis_state: Make unsubscribes NULL tolerant Regular stasis unsubscribes can handle NULL subscription objects. This patch makes it so stasis state unsubscribes handles NULL's as well. ASTERISK-28442 Change-Id: Ic3648e8df043a85b77cff085e9ff10356028e479	6 years ago
Kevin Harwell	363bafc29e	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	6 years ago

5 Commits (6c9e8afd4ea55a33680ee580658230b51f307292)