[reSIProcate] Proposal for Making DUM and Multi-threaded application 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.