[sr-dev] git:master: tm: callbacks: obsolate description is removed.

Miklos Tirpak miklos at iptel.org
Thu Jun 11 16:55:25 CEST 2009


Module: sip-router
Branch: master
Commit: 09b7b0b356153335bcbb17220397f2a20801d4a2
URL:    http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=09b7b0b356153335bcbb17220397f2a20801d4a2

Author: Miklos Tirpak <miklos at iptel.org>
Committer: Miklos Tirpak <miklos at iptel.org>
Date:   Thu Jun 11 16:53:59 2009 +0200

tm: callbacks: obsolate description is removed.

The description about the callback insertion was
confusing because no locking is necessary to insert
new callbacks.

---

 modules/tm/t_hooks.h |   14 +++-----------
 1 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/modules/tm/t_hooks.h b/modules/tm/t_hooks.h
index 48b0d59..998ace1 100644
--- a/modules/tm/t_hooks.h
+++ b/modules/tm/t_hooks.h
@@ -146,21 +146,13 @@ struct cell;
  * incomplete -- this callback is called in very early stage
  * before the message is shmem-ized (so that you can work
  * with it).
- * It's safe to install other TMCB callbacks from here.
  * Note: this callback MUST be installed before forking
  * (the req_in_tmcb_hl callback list does not live in shmem and has no access
  * protection), i.e., at best from mod_init functions.
  *
- * Note: all the other callbacks MUST be installed before or immediately after
- *  the transaction is created (they must not be installed from any place 
- *  where the transaction callbacks can be run or added simultaneously with 
- *  the add operation). Another safe way of installing them is to hold the
- *  REPLY lock prior to adding a callback.
- *  In general it's not safe to register callbacks from other TMCB callbacks,
- *  unless the contrary is explicitly stated in the TMCB callback description.
- *  For example a good place for installing them is from a TMCB_REQUEST_IN 
- *  callback.
- *
+ * Note: All the other callbacks can be safely installed when the
+ * transaction already exists, it does not need to be locked.
+ * 
  * TMCB_RESPONSE_IN -- a brand-new reply was received which matches
  * an existing non-local transaction. It may or may not be a retransmission.
  * No lock is held here (yet).




More information about the sr-dev mailing list