DUM Threading

From reSIProcate
Revision as of 07:17, 11 April 2006 by Sgodin (talk | contribs) (a little new content)
Jump to navigation Jump to search

The Dialog Usage Manager (DUM) supports a few threading options - which are summarized below.

NOTE: There is no threading protection in the DUM methods themseleves. If your application itself is multi-threaded you MUST provide your own protection (mutexing) if you plan on calling dum->process and/or other DUM API's from different threads. This can also be accomplished by queueing DumCommands to the dum process loop from your application threads.


Single Threaded

Your application, DUM, the stack and transports all run in the same thread. This is how the BasicCall sample works. A process loop is required:

  while (!dumShutDown)
  {
     FdSet fdset;
     stack->buildFdSet(fdset);
     int err = fdset.selectMilliSeconds(stack->getTimeTillNextProcessMS());
     assert ( err != -1 );
     stack->process(fdset);
     while(dumUas->process());
  }


Separate Stack Thread

Your application and DUM run in the same thread, the stack and transports run in another thread. To run in this mode you must use or emulate the functionality in StackThread.cxx to startup and run the stack thread. Then you must periodically call the dum->process() method from your application so that DUM can peform its processing. The important thing to remember here, is that DUM is not part of the core stack, it sits on top.


Separate DUM and/or Stack Threads

A class called DumThread is in the works. This will allow you to run all of resiprocate in it's own thread (or threads) and your application in another thread. You can use StackThread and DumThread together to have the stack and dum run in seperate threads. In this scenario your application runs in it's own seperate thread.

NOTE: There is no threading protection in the DUM methods themseleves. If your application itself is multi-threaded you MUST provide your own protection (mutexing) if you plan on calling dum->process and/or other DUM API's from different threads. This can also be accomplished by queueing DumCommands to the dum process loop from your application threads.

A good sample of use of both StackThread and DumThread can be found in the repro proxy server - look at repro/repro.cxx