sysmocom
/
asterisk
11
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
asterisk/main/stasis_state.c

772 lines
20 KiB
C
Raw Normal View History

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
2019-06-11 17:30:27 +00:00
/*
* Asterisk -- An open source telephony toolkit.
*
* Copyright (C) 2019, Sangoma Technologies Corporation
*
* Kevin Harwell <kharwell@digium.com>
*
* See http://www.asterisk.org for more information about
* the Asterisk project. Please do not directly contact
* any of the maintainers of this project for assistance;
* the project provides a web site, mailing lists and IRC
* channels for your use.
*
* This program is free software, distributed under the terms of
* the GNU General Public License Version 2. See the LICENSE file
* at the top of the source tree.
*/
/*** MODULEINFO
<support_level>core</support_level>
***/
#include "asterisk.h"
#include "asterisk/stasis_state.h"
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
2019-09-20 14:08:02 +00:00
/*!
* \internal
* \brief Used to link a stasis_state to it's manager
*/
struct stasis_state_proxy {
AO2_WEAKPROXY();
/*! The manager that owns and handles this state */
struct stasis_state_manager *manager;
/*! A unique id for this state object. */
char id[0];
};
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
2019-06-11 17:30:27 +00:00
/*!
* \internal
* \brief Associates a stasis topic to its last known published message
*
* This object's lifetime is tracked by the number of publishers and subscribers to it.
* Once all publishers and subscribers have been removed this object is removed from the
* manager's collection and destroyed. While a single object type (namely this one) could
* be utilized for both publishers, and subscribers this implementation purposely keeps
* them separated. This was done to maintain readability, make debugging easier, and allow
* for better logging and future enhancements.
*/
struct stasis_state {
/*! The number of state subscribers */
unsigned int num_subscribers;
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
2019-09-20 14:08:02 +00:00
/*!
* \brief The manager that owns and handles this state
* \note This reference is owned by stasis_state_proxy
*/
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
2019-06-11 17:30:27 +00:00
struct stasis_state_manager *manager;
/*! Forwarding information, i.e. this topic to manager's topic */
struct stasis_forward *forward;
/*! The managed topic */
struct stasis_topic *topic;
/*! The actual state data */
struct stasis_message *msg;
/*!
* A container of eids. It's assumed that there is only a single publisher per
* eid per topic. Thus the publisher is tracked by the system's eid.
*/
AST_VECTOR(, struct ast_eid) eids;
/*! A unique id for this state object. */
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
2019-09-20 14:08:02 +00:00
char *id;
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
2019-06-11 17:30:27 +00:00
};
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
2019-09-20 14:08:02 +00:00
AO2_STRING_FIELD_HASH_FN(stasis_state_proxy, id);
AO2_STRING_FIELD_CMP_FN(stasis_state_proxy, id);
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
2019-06-11 17:30:27 +00:00
/*! The number of buckets to use for managed states */
#define STATE_BUCKETS 57
struct stasis_state_manager {
/*! Holds all state objects handled by this manager */
struct ao2_container *states;
/*! The manager's topic. All state topics are forward to this one */
struct stasis_topic *all_topic;
/*! A collection of manager event handlers */
AST_VECTOR_RW(, struct stasis_state_observer *) observers;
};
/*!
* \internal
* \brief Retrieve a state's topic name without the manager topic.
*
* State topics have names that consist of the manager's topic name
* combined with a unique id separated by a slash. For instance:
*
* manager topic's name/unique id
*
* This method retrieves the unique id part from the state's topic name.
*
* \param manager_topic The manager's topic
* \param state_topic A state topic
*
* \return The state's topic unique id
*/
static const char *state_id_by_topic(struct stasis_topic *manager_topic,
const struct stasis_topic *state_topic)
{
const char *id;
/* This topic should always belong to the manager */
ast_assert(ast_begins_with(stasis_topic_name(manager_topic),
stasis_topic_name(state_topic)));
id = strchr(stasis_topic_name(state_topic), '/');
/* The state's unique id should always exist */
GCC12: Fixes for 18+. state_id_by_topic comparing wrong value GCC 12 caught an issue in state_id_by_topic where we were checking a pointer for NULL instead of the contents of the pointer for '\0'. ASTERISK-30044 Change-Id: Ia0b04d4fff45c92acb7f07132a33622fa341148e
2022-05-04 18:00:27 +00:00
ast_assert(id != NULL && *(id + 1) != '\0');
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
2019-06-11 17:30:27 +00:00
return (id + 1);
}
static void state_dtor(void *obj)
{
struct stasis_state *state = obj;
state->forward = stasis_forward_cancel(state->forward);
ao2_cleanup(state->topic);
state->topic = NULL;
ao2_cleanup(state->msg);
state->msg = NULL;
/* All eids should have been removed */
ast_assert(AST_VECTOR_SIZE(&state->eids) == 0);
AST_VECTOR_FREE(&state->eids);
}
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
2019-09-20 14:08:02 +00:00
static void state_proxy_dtor(void *obj) {
struct stasis_state_proxy *proxy = obj;
ao2_cleanup(proxy->manager);
}
static void state_proxy_sub_cb(void *obj, void *data)
{
struct stasis_state_proxy *proxy = obj;
ao2_unlink(proxy->manager->states, proxy);
}
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
2019-06-11 17:30:27 +00:00
/*!
* \internal
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
2019-09-20 14:08:02 +00:00
* \brief Allocate a stasis state object and add it to the manager.
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
2019-06-11 17:30:27 +00:00
*
* Create and initialize a state structure. It's required that either a state
* topic, or an id is specified. If a state topic is not given then one will be
* created using the given id.
*
* \param manager The owning manager
* \param state_topic A state topic to be managed
* \param id The unique id for the state
stasis: Fix for Doxygen. ASTERISK-29750 Change-Id: Iea50173e785b2e9d49bc24c0af7111cfd96d44a9
2021-11-16 16:26:23 +00:00
* \param file, line, func
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
2019-06-11 17:30:27 +00:00
*
* \return A stasis_state object or NULL
stasis: Fix for Doxygen. ASTERISK-29750 Change-Id: Iea50173e785b2e9d49bc24c0af7111cfd96d44a9
2021-11-16 16:26:23 +00:00
* \retval NULL on error
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
2019-09-20 14:08:02 +00:00
*
* \pre manager->states must be locked.
* \pre manager->states does not contain an object matching key \a id.
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
2019-06-11 17:30:27 +00:00
*/
static struct stasis_state *state_alloc(struct stasis_state_manager *manager,
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
2019-09-20 14:08:02 +00:00
struct stasis_topic *state_topic, const char *id,
const char *file, int line, const char *func)
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
2019-06-11 17:30:27 +00:00
{
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
2019-09-20 14:08:02 +00:00
struct stasis_state_proxy *proxy = NULL;
struct stasis_state *state = NULL;
if (!id) {
/* If not given an id, then a state topic is required */
ast_assert(state_topic != NULL);
/* Get the id we'll key off of from the state topic */
id = state_id_by_topic(manager->all_topic, state_topic);
}
state = __ao2_alloc(sizeof(*state), state_dtor, AO2_ALLOC_OPT_LOCK_MUTEX, id, file, line, func);
if (!state) {
goto error_return;
}
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
2019-06-11 17:30:27 +00:00
if (!state_topic) {
char *name;
/*
* To provide further detail and to ensure that the topic is unique within the
* scope of the system we prefix it with the manager's topic name, which should
* itself already be unique.
*/
if (ast_asprintf(&name, "%s/%s", stasis_topic_name(manager->all_topic), id) < 0) {
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
2019-09-20 14:08:02 +00:00
goto error_return;
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
2019-06-11 17:30:27 +00:00
}
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
2019-09-20 14:08:02 +00:00
state->topic = stasis_topic_create(name);
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
2019-06-11 17:30:27 +00:00
ast_free(name);
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
2019-09-20 14:08:02 +00:00
if (!state->topic) {
goto error_return;
}
stasis: Fix leaks * Release reference returned by cache_remove * state_alloc unconditionally bumped state_topic even when it was locally allocated. Change-Id: I51101bf7d07b8dc8ce8fc46b6cb31fbbd213fbc7
2019-09-19 22:32:56 +00:00
} else {
/*
* Since the state topic was passed in, go ahead and bump its reference.
* By doing this here first, it allows us to consistently decrease the reference on
* state allocation error.
*/
ao2_ref(state_topic, +1);
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
2019-09-20 14:08:02 +00:00
state->topic = state_topic;
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
2019-06-11 17:30:27 +00:00
}
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
2019-09-20 14:08:02 +00:00
proxy = ao2_t_weakproxy_alloc(sizeof(*proxy) + strlen(id) + 1, state_proxy_dtor, id);
if (!proxy) {
goto error_return;
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
2019-06-11 17:30:27 +00:00
}
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
2019-09-20 14:08:02 +00:00
strcpy(proxy->id, id); /* Safe */
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
2019-06-11 17:30:27 +00:00
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
2019-09-20 14:08:02 +00:00
state->id = proxy->id;
proxy->manager = ao2_bump(manager);
state->manager = proxy->manager; /* state->manager is owned by the proxy */
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
2019-06-11 17:30:27 +00:00
state->forward = stasis_forward_all(state->topic, manager->all_topic);
if (!state->forward) {
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
2019-09-20 14:08:02 +00:00
goto error_return;
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
2019-06-11 17:30:27 +00:00
}
if (AST_VECTOR_INIT(&state->eids, 2)) {
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
2019-09-20 14:08:02 +00:00
goto error_return;
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
2019-06-11 17:30:27 +00:00
}
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
2019-09-20 14:08:02 +00:00
if (ao2_t_weakproxy_set_object(proxy, state, OBJ_NOLOCK, "weakproxy link")) {
goto error_return;
}
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
2019-06-11 17:30:27 +00:00
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
2019-09-20 14:08:02 +00:00
if (ao2_weakproxy_subscribe(proxy, state_proxy_sub_cb, NULL, OBJ_NOLOCK)) {
goto error_return;
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
2019-06-11 17:30:27 +00:00
}
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
2019-09-20 14:08:02 +00:00
if (!ao2_link_flags(manager->states, proxy, OBJ_NOLOCK)) {
goto error_return;
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
2019-06-11 17:30:27 +00:00
}
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
2019-09-20 14:08:02 +00:00
ao2_ref(proxy, -1);
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
2019-06-11 17:30:27 +00:00
return state;
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
2019-09-20 14:08:02 +00:00
error_return:
ast_log(LOG_ERROR, "Unable to allocate state '%s' in manager '%s'\n",
id, stasis_topic_name(manager->all_topic));
ao2_cleanup(state);
ao2_cleanup(proxy);
return NULL;
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
2019-06-11 17:30:27 +00:00
}
/*!
* \internal
* \brief Find a state by id, or create one if not found and add it to the manager.
*
* \param manager The manager to be added to
* \param state_topic A state topic to be managed (if NULL id is required)
* \param id The unique id for the state (if NULL state_topic is required)
*
* \return The added state object
stasis: Fix for Doxygen. ASTERISK-29750 Change-Id: Iea50173e785b2e9d49bc24c0af7111cfd96d44a9
2021-11-16 16:26:23 +00:00
* \retval NULL on error
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
2019-06-11 17:30:27 +00:00
*/
stasis: Fix for Doxygen. ASTERISK-29750 Change-Id: Iea50173e785b2e9d49bc24c0af7111cfd96d44a9
2021-11-16 16:26:23 +00:00
#define state_find_or_add(manager, state_topic, id) __state_find_or_add(manager, state_topic, id, __FILE__, __LINE__, __PRETTY_FUNCTION__)
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
2019-09-20 14:08:02 +00:00
static struct stasis_state *__state_find_or_add(struct stasis_state_manager *manager,
struct stasis_topic *state_topic, const char *id,
const char *file, int line, const char *func)
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
2019-06-11 17:30:27 +00:00
{
struct stasis_state *state;
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
2019-09-20 14:08:02 +00:00
ao2_lock(manager->states);
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
2019-06-11 17:30:27 +00:00
if (ast_strlen_zero(id)) {
id = state_id_by_topic(manager->all_topic, state_topic);
}
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
2019-09-20 14:08:02 +00:00
state = ao2_weakproxy_find(manager->states, id, OBJ_SEARCH_KEY | OBJ_NOLOCK, "");
if (!state) {
state = state_alloc(manager, state_topic, id, file, line, func);
}
ao2_unlock(manager->states);
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
2019-06-11 17:30:27 +00:00
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
2019-09-20 14:08:02 +00:00
return state;
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
2019-06-11 17:30:27 +00:00
}
static void state_manager_dtor(void *obj)
{
struct stasis_state_manager *manager = obj;
#ifdef AO2_DEBUG
{
char *container_name =
ast_alloca(strlen(stasis_topic_name(manager->all_topic)) + strlen("-manager") + 1);
sprintf(container_name, "%s-manager", stasis_topic_name(manager->all_topic));
ao2_container_unregister(container_name);
}
#endif
ao2_cleanup(manager->states);
manager->states = NULL;
ao2_cleanup(manager->all_topic);
manager->all_topic = NULL;
AST_VECTOR_RW_FREE(&manager->observers);
}
#ifdef AO2_DEBUG
static void state_prnt_obj(void *v_obj, void *where, ao2_prnt_fn *prnt)
{
struct stasis_state *state = v_obj;
if (!state) {
return;
}
prnt(where, "%s", stasis_topic_name(state->topic));
}
#endif
struct stasis_state_manager *stasis_state_manager_create(const char *topic_name)
{
struct stasis_state_manager *manager;
manager = ao2_alloc_options(sizeof(*manager), state_manager_dtor,
AO2_ALLOC_OPT_LOCK_NOLOCK);
if (!manager) {
return NULL;
}
manager->states = ao2_container_alloc_hash(AO2_ALLOC_OPT_LOCK_MUTEX, 0,
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
2019-09-20 14:08:02 +00:00
STATE_BUCKETS, stasis_state_proxy_hash_fn, NULL, stasis_state_proxy_cmp_fn);
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
2019-06-11 17:30:27 +00:00
if (!manager->states) {
ao2_ref(manager, -1);
return NULL;
}
manager->all_topic = stasis_topic_create(topic_name);
if (!manager->all_topic) {
ao2_ref(manager, -1);
return NULL;
}
if (AST_VECTOR_RW_INIT(&manager->observers, 2) != 0) {
ao2_ref(manager, -1);
return NULL;
}
#ifdef AO2_DEBUG
{
char *container_name =
ast_alloca(strlen(stasis_topic_name(manager->all_topic)) + strlen("-manager") + 1);
sprintf(container_name, "%s-manager", stasis_topic_name(manager->all_topic));
ao2_container_register(container_name, manager->states, state_prnt_obj);
}
#endif
return manager;
}
struct stasis_topic *stasis_state_all_topic(struct stasis_state_manager *manager)
{
return manager->all_topic;
}
struct stasis_topic *stasis_state_topic(struct stasis_state_manager *manager, const char *id)
{
struct stasis_topic *topic;
struct stasis_state *state;
state = state_find_or_add(manager, NULL, id);
if (!state) {
return NULL;
}
topic = state->topic;
ao2_ref(state, -1);
return topic;
}
struct stasis_state_subscriber {
/*! The stasis state subscribed to */
struct stasis_state *state;
/*! The stasis subscription. */
struct stasis_subscription *stasis_sub;
};
static void subscriber_dtor(void *obj)
{
size_t i;
struct stasis_state_subscriber *sub = obj;
struct stasis_state_manager *manager = sub->state->manager;
AST_VECTOR_RW_RDLOCK(&manager->observers);
for (i = 0; i < AST_VECTOR_SIZE(&manager->observers); ++i) {
if (AST_VECTOR_GET(&manager->observers, i)->on_unsubscribe) {
AST_VECTOR_GET(&manager->observers, i)->on_unsubscribe(sub->state->id, sub);
}
}
AST_VECTOR_RW_UNLOCK(&manager->observers);
ao2_lock(sub->state);
--sub->state->num_subscribers;
ao2_unlock(sub->state);
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
2019-09-20 14:08:02 +00:00
ao2_ref(sub->state, -1);
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
2019-06-11 17:30:27 +00:00
}
struct stasis_state_subscriber *stasis_state_add_subscriber(
struct stasis_state_manager *manager, const char *id)
{
size_t i;
struct stasis_state_subscriber *sub = ao2_alloc_options(
sizeof(*sub), subscriber_dtor, AO2_ALLOC_OPT_LOCK_NOLOCK);
if (!sub) {
ast_log(LOG_ERROR, "Unable to create subscriber to %s/%s\n",
stasis_topic_name(manager->all_topic), id);
return NULL;
}
sub->state = state_find_or_add(manager, NULL, id);
if (!sub->state) {
ao2_ref(sub, -1);
return NULL;
}
ao2_lock(sub->state);
++sub->state->num_subscribers;
ao2_unlock(sub->state);
AST_VECTOR_RW_RDLOCK(&manager->observers);
for (i = 0; i < AST_VECTOR_SIZE(&manager->observers); ++i) {
if (AST_VECTOR_GET(&manager->observers, i)->on_subscribe) {
AST_VECTOR_GET(&manager->observers, i)->on_subscribe(id, sub);
}
}
AST_VECTOR_RW_UNLOCK(&manager->observers);
return sub;
}
struct stasis_state_subscriber *stasis_state_subscribe_pool(struct stasis_state_manager *manager,
const char *id, stasis_subscription_cb callback, void *data)
{
struct stasis_topic *topic;
struct stasis_state_subscriber *sub = stasis_state_add_subscriber(manager, id);
if (!sub) {
return NULL;
}
topic = sub->state->topic;
ast_debug(3, "Creating stasis state subscription to id '%s'. Topic: '%s':%p %d\n",
id, stasis_topic_name(topic), topic, (int)ao2_ref(topic, 0));
sub->stasis_sub = stasis_subscribe_pool(topic, callback, data);
if (!sub->stasis_sub) {
ao2_ref(sub, -1);
return NULL;
}
return sub;
}
void *stasis_state_unsubscribe(struct stasis_state_subscriber *sub)
{
sub->stasis_sub = stasis_unsubscribe(sub->stasis_sub);
ao2_ref(sub, -1);
return NULL;
}
void *stasis_state_unsubscribe_and_join(struct stasis_state_subscriber *sub)
{
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
2019-07-08 23:10:07 +00:00
if (sub) {
sub->stasis_sub = stasis_unsubscribe_and_join(sub->stasis_sub);
ao2_ref(sub, -1);
}
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
2019-06-11 17:30:27 +00:00
return NULL;
}
const char *stasis_state_subscriber_id(const struct stasis_state_subscriber *sub)
{
return sub->state->id;
}
struct stasis_topic *stasis_state_subscriber_topic(struct stasis_state_subscriber *sub)
{
return sub->state->topic;
}
void *stasis_state_subscriber_data(struct stasis_state_subscriber *sub)
{
void *res;
/*
* The data's reference needs to be bumped before returning so it doesn't disappear
* for the caller. Lock state, so the underlying message data is not replaced while
* retrieving.
*/
ao2_lock(sub->state);
res = ao2_bump(stasis_message_data(sub->state->msg));
ao2_unlock(sub->state);
return res;
}
struct stasis_subscription *stasis_state_subscriber_subscription(
struct stasis_state_subscriber *sub)
{
return sub->stasis_sub;
}
struct stasis_state_publisher {
/*! The stasis state to publish to */
struct stasis_state *state;
};
static void publisher_dtor(void *obj)
{
struct stasis_state_publisher *pub = obj;
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
2019-09-20 14:08:02 +00:00
ao2_ref(pub->state, -1);
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
2019-06-11 17:30:27 +00:00
}
struct stasis_state_publisher *stasis_state_add_publisher(
struct stasis_state_manager *manager, const char *id)
{
struct stasis_state_publisher *pub = ao2_alloc_options(
sizeof(*pub), publisher_dtor, AO2_ALLOC_OPT_LOCK_NOLOCK);
if (!pub) {
ast_log(LOG_ERROR, "Unable to create publisher to %s/%s\n",
stasis_topic_name(manager->all_topic), id);
return NULL;
}
pub->state = state_find_or_add(manager, NULL, id);
if (!pub->state) {
ao2_ref(pub, -1);
return NULL;
}
return pub;
}
const char *stasis_state_publisher_id(const struct stasis_state_publisher *pub)
{
return pub->state->id;
}
struct stasis_topic *stasis_state_publisher_topic(struct stasis_state_publisher *pub)
{
return pub->state->topic;
}
void stasis_state_publish(struct stasis_state_publisher *pub, struct stasis_message *msg)
{
ao2_lock(pub->state);
ao2_replace(pub->state->msg, msg);
ao2_unlock(pub->state);
stasis_publish(pub->state->topic, msg);
}
/*!
* \internal
* \brief Find, or add the given eid to the state object
*
* Publishers can be tracked implicitly using eids. This allows us to add, and subsequently
* remove state objects from the managed states container in a deterministic way. Using the
* eids in this way is possible because it's guaranteed that there will only ever be a single
* publisher for a uniquely named topic (topics tracked by this module) on a system.
*
* \note The vector does not use locking. Instead we use the state object for that, so it
* needs to be locked prior to calling this method.
*
* \param state The state object
* \param eid The system id to add to the state object
*/
static void state_find_or_add_eid(struct stasis_state *state, const struct ast_eid *eid)
{
size_t i;
if (!eid) {
eid = &ast_eid_default;
}
for (i = 0; i < AST_VECTOR_SIZE(&state->eids); ++i) {
if (!ast_eid_cmp(AST_VECTOR_GET_ADDR(&state->eids, i), eid)) {
break;
}
}
if (i == AST_VECTOR_SIZE(&state->eids)) {
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
2019-09-20 14:08:02 +00:00
if (!AST_VECTOR_APPEND(&state->eids, *eid)) {
/* This ensures state cannot be freed if it has any eids */
ao2_ref(state, +1);
}
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
2019-06-11 17:30:27 +00:00
}
}
/*!
* \internal
* \brief Find, and remove the given eid from the state object
*
* Used to remove an eid from an implicit publisher.
*
* \note The vector does not use locking. Instead we use the state object for that, so it
* needs to be locked prior to calling this method.
*
* \param state The state object
* \param eid The system id to remove from the state object
*/
static void state_find_and_remove_eid(struct stasis_state *state, const struct ast_eid *eid)
{
size_t i;
if (!eid) {
eid = &ast_eid_default;
}
for (i = 0; i < AST_VECTOR_SIZE(&state->eids); ++i) {
if (!ast_eid_cmp(AST_VECTOR_GET_ADDR(&state->eids, i), eid)) {
AST_VECTOR_REMOVE_UNORDERED(&state->eids, i);
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
2019-09-20 14:08:02 +00:00
/* Balance the reference from state_find_or_add_eid */
ao2_ref(state, -1);
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
2019-06-11 17:30:27 +00:00
return;
}
}
}
void stasis_state_publish_by_id(struct stasis_state_manager *manager, const char *id,
const struct ast_eid *eid, struct stasis_message *msg)
{
struct stasis_state *state;
state = state_find_or_add(manager, NULL, id);
if (!state) {
return;
}
ao2_lock(state);
state_find_or_add_eid(state, eid);
ao2_replace(state->msg, msg);
ao2_unlock(state);
stasis_publish(state->topic, msg);
ao2_ref(state, -1);
}
void stasis_state_remove_publish_by_id(struct stasis_state_manager *manager,
const char *id, const struct ast_eid *eid, struct stasis_message *msg)
{
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
2019-09-20 14:08:02 +00:00
struct stasis_state *state = ao2_weakproxy_find(manager->states, id, OBJ_SEARCH_KEY, "");
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
2019-06-11 17:30:27 +00:00
if (!state) {
/*
* In most circumstances state should already exist here. However, if there is no
* state then it can mean one of a few things:
*
* 1. This function was called prior to an implicit publish for the same given
* manager, and id.
* 2. This function was called more than once for the same manager, and id.
* 3. There is ref count problem with the explicit subscribers, and publishers.
*/
ast_debug(5, "Attempted to remove state for id '%s', but state not found\n", id);
return;
}
if (msg) {
stasis_publish(state->topic, msg);
}
ao2_lock(state);
state_find_and_remove_eid(state, eid);
ao2_unlock(state);
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
2019-09-20 14:08:02 +00:00
ao2_ref(state, -1);
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
2019-06-11 17:30:27 +00:00
}
int stasis_state_add_observer(struct stasis_state_manager *manager,
struct stasis_state_observer *observer)
{
int res;
AST_VECTOR_RW_WRLOCK(&manager->observers);
res = AST_VECTOR_APPEND(&manager->observers, observer);
AST_VECTOR_RW_UNLOCK(&manager->observers);
return res;
}
void stasis_state_remove_observer(struct stasis_state_manager *manager,
struct stasis_state_observer *observer)
{
AST_VECTOR_RW_WRLOCK(&manager->observers);
AST_VECTOR_REMOVE_ELEM_UNORDERED(&manager->observers, observer, AST_VECTOR_ELEM_CLEANUP_NOOP);
AST_VECTOR_RW_UNLOCK(&manager->observers);
}
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
2019-09-20 14:08:02 +00:00
static int handle_stasis_state(struct stasis_state *state, on_stasis_state handler, void *data)
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
2019-06-11 17:30:27 +00:00
{
struct stasis_message *msg;
int res;
/*
* State needs to be locked here while we retrieve and bump the reference on its message
* object. Doing so guarantees the message object will live throughout its handling.
*/
ao2_lock(state);
msg = ao2_bump(state->msg);
ao2_unlock(state);
res = handler(state->id, msg, data);
ao2_cleanup(msg);
return res;
}
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
2019-09-20 14:08:02 +00:00
static int handle_stasis_state_proxy(void *obj, void *arg, void *data, int flags)
{
struct stasis_state *state = ao2_weakproxy_get_object(obj, 0);
if (state) {
int res;
res = handle_stasis_state(state, arg, data);
ao2_ref(state, -1);
return res;
}
return 0;
}
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
2019-06-11 17:30:27 +00:00
void stasis_state_callback_all(struct stasis_state_manager *manager, on_stasis_state handler,
void *data)
{
ast_assert(handler != NULL);
ao2_callback_data(manager->states, OBJ_MULTIPLE | OBJ_NODATA,
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
2019-09-20 14:08:02 +00:00
handle_stasis_state_proxy, handler, data);
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
2019-06-11 17:30:27 +00:00
}
static int handle_stasis_state_subscribed(void *obj, void *arg, void *data, int flags)
{
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
2019-09-20 14:08:02 +00:00
struct stasis_state *state = ao2_weakproxy_get_object(obj, 0);
int res = 0;
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
2019-06-11 17:30:27 +00:00
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
2019-09-20 14:08:02 +00:00
if (state && state->num_subscribers) {
res = handle_stasis_state(state, arg, data);
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
2019-06-11 17:30:27 +00:00
}
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
2019-09-20 14:08:02 +00:00
ao2_cleanup(state);
return res;
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
2019-06-11 17:30:27 +00:00
}
void stasis_state_callback_subscribed(struct stasis_state_manager *manager, on_stasis_state handler,
void *data)
{
ast_assert(handler != NULL);
ao2_callback_data(manager->states, OBJ_MULTIPLE | OBJ_NODATA,
handle_stasis_state_subscribed, handler, data);
}