RE: [reSIProcate] Proposal for Making DUM and Multi-threadedapplication thread safe
There is a construct for creating what you are thinking of... Have a look at
DumCommand.hxx - an example of it's use can be found in the bbridge
application in the sipX SVN repository.
Scott
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Asheesh
Joshi
Sent: Friday, December 30, 2005 2:27 AM
To: 'resiprocate-devel'
Subject: [reSIProcate] Proposal for Making DUM and Multi-threadedapplication
thread safe
Hi all,
There is a design that I would like to discuss to make DUM and
mulit-threaded application thread safe.
Since our team is designing a B2BUA using a multi-threaded application on
top of DUM, we feel that the current DUM interface needs some design changes
to make this happen.
Current the architecture demands DUM and application to run in the
same thread context. I had read some Wiki document which does talk of
multi-threading and the suggested the use of mutex around DUM APIs and /or
dum-process ( ). Well, even though this will make the design thread safe, I
guess the application may loose on the advantages of "multi-threading".
Since a lot of people will ( and probably would have ) tuned
Resiprocate to their needs, it will be good if we can come up with a clean
interface ( something similar to DUM callbacks ), which will help the
application thread ( or to be more generic any thread ) to directly enqueue
message in the DUM queue. Then the queue processing should be modified in
DUM to differentiate messages coming from the application thread v/s
messages coming from the stack.
The messages coming from the Stack will be treated the way they are
today, but new code will have to be added to DUM for handling packets
received from application thread. The packets sent from application will
contain information on what DUM API has to be used. This will ensure proper
and sequenced processing of DUM APIs from a multi-threaded application.
Any issues such a design could have ? Please comment.
-Regards
Asheesh.
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel