Modify the documentation of the sip_registry struct

- Remove a comment that says that the monitor thread is the only one that
   ever touches these objects.  This is no longer the case with TCP.  Also,
   I would eventually like to get the scheduler in its own thread, so this
   is just a poor assumption to make.
 - Note that reference counting of these objects with respect to scheduler
   entries is not complete.  There are some leaked references when deleting
   scheduler entries.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1.6.2
Russell Bryant 17 years ago
parent be467d0cea
commit 3d5b3249a8

@ -1657,7 +1657,9 @@ struct sip_peer {
}; };
/*! \brief Registrations with other SIP proxies /*!
* \brief Registrations with other SIP proxies
*
* Created by sip_register(), the entry is linked in the 'regl' list, * Created by sip_register(), the entry is linked in the 'regl' list,
* and never deleted (other than at 'sip reload' or module unload times). * and never deleted (other than at 'sip reload' or module unload times).
* The entry always has a pending timeout, either waiting for an ACK to * The entry always has a pending timeout, either waiting for an ACK to
@ -1666,11 +1668,12 @@ struct sip_peer {
* or once the previously completed registration one expires). * or once the previously completed registration one expires).
* The registration can be in one of many states, though at the moment * The registration can be in one of many states, though at the moment
* the handling is a bit mixed. * the handling is a bit mixed.
* Note that the entire evolution of sip_registry (transmissions, *
* incoming packets and timeouts) is driven by one single thread, * XXX \todo Reference count handling for this object has some problems with
* do_monitor(), so there is almost no synchronization issue. * respect to scheduler entries. The ref count is handled in some places,
* The only exception is the sip_pvt creation/lookup, * but not all of them. There are some places where references get leaked
* as the dialoglist is also manipulated by other threads. * when this scheduler entry gets cancelled. At worst, this would cause
* memory leaks on reloads if registrations get removed from configuration.
*/ */
struct sip_registry { struct sip_registry {
ASTOBJ_COMPONENTS_FULL(struct sip_registry,1,1); ASTOBJ_COMPONENTS_FULL(struct sip_registry,1,1);
@ -4756,7 +4759,6 @@ static void sip_registry_destroy(struct sip_registry *reg)
ast_atomic_fetchadd_int(&regobjs, -1); ast_atomic_fetchadd_int(&regobjs, -1);
ast_dnsmgr_release(reg->dnsmgr); ast_dnsmgr_release(reg->dnsmgr);
ast_free(reg); ast_free(reg);
} }
/*! \brief Destroy MWI subscription object */ /*! \brief Destroy MWI subscription object */

Loading…
Cancel
Save