2010/3/18 Aleksander Morgado <aleksan...@gnu.org>: ... > Now, in order to avoid this, the idea is to just make sure that at least > one reference of the msg_t is available while we process the reply in > thread B. This could be managed if inside our callback stored in > orq->orq_callback we could call msg_ref_create() and call ourselves > msg_destroy() when we no longer need to process the associated sip_t.
It seems to me that your solution with msg_t reference fine. > Of course, with this solution we just avoid the invalid reads in > valgrind, but, still we will see that retransmissions arrive to the > nta_agent_t and they are not treated as retransmissions, as we still > didn't 'complete' the outgoing request in thread B while received the > new message in thread A. Any possible way of avoiding this? You have to keep track of 2XX responses to INVITE somehow. Perhaps easiest way is to create a tagged outgoing transaction with nta_outgoing_tagged() before handling the 200 OK to thread B. If the stack receives a new 200 OK with the same To tag, it should be fed to the tagged transaction and its callback, not the original one. (However, please note that the code dealing with the tagged transactions is not very throughly tested.) A simpler method would just store the To tag and check that (and drop the newly received 200 OK if the tags match.) In any case, you are left with an interesting problem: what to do with two 200 OK messages from two different endpoints. -- Pekka.Pessi mail at nokia.com ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
