[reSIProcate] Alternative "async/external" Processing Model

[Bellanger Julien]

Hi,

I have some questions about how to safely use the AsyncProcessHandler
which is passed to the DUM constructor.

In my anderstanting this handler is notified in these cases:
- when the transport Layer post a message to the Stack Fifo,
- when the Stack find a timer fired and post it to the Stack Fifo or TU Fifo,
- when the Stack post an Event to the TU Fifo

So the AsyncProcessHandler is called when there is an event for the
Stack OR the DUM,
Is this means that the Stack and DUM should run in the same Thread
when using the async processing model ?
In my advise, it could be interresting to have two type of AsyncProcessHandler:
one for the Stack Event and one for the TU Event.

Furthermore, in a Multithread model, the AsyncProcessHandler can be called from
Transport Layer Threads or Stack Thread, and I read that the DUM API isn't
thread safe, so we can't safely use the DUM API in this AsyncProcessHandler.

Thus the DumProcessHandler sample gived in the Dum project seems not be used
safely in a multithread model.

In the multithread model, the AsyncProcessHandler could just wake up the DUM
thread via a System Event on which it call the proccess() method.
Thus a DUM thread could wait on external event and be waked up by the stack
only when a TU event is avaible, without continuously pooling on process method.

Are you agree with that or am I in a wrong way ?


Thanks for your answers


Julien




----- Original Message -----
  From: derek
  To: resiprocate-devel at list.sipfoundry.org
  Sent: Wednesday, March 16, 2005 9:49 PM
  Subject: [reSIProcate] Merged in my xten-async branch, some minor API changes


  At long last this is merged in, along with some other fixes that I spotted along the way. Here's the commit log, mangled a bit by outlook.

  

  Major changes:

  

  Alternative "async/external" Processing Model

  

  The SipStack & DUM can now run w/out being in a build/select/process

  loop.  This is accomplished witht ransports that provide their own cycles, as well

  as an external timer api.  The SipStack is constructed w/ an

  AsyncProcessHandler which gets notified when a message is put into the

  StateMacFifo, or when SipStack::postMs or SipStack::post is called.  This can be

  optimized a bit more; in some cases only a timer adjustment may be required, but

  the stack might not require cycles.  DumProcessHandler, located in the Dum

  directory, is a example of how to use this.  Note that it provides ares w/ a 50

  ms timer when there is an active query.  DnsInterface now has a requiresProcess

  method to facilitate this; it should possibly become another

  getTimeTillNextProcess method.

  

  Transport Refactoring/Cleanup

  

  TransportSelector now only understands objects that derive from Transport.  The

  SipStack is responsible for the Transport Factory behaviour of addTransport.  A

  lot of the Transport has moved into InternalTransport, to keep the Transport

  abstraction clean.  Also, the tcp transports have been cleaned up; most of dlb's

  rant in ConnectionBase.hxx has been answered.

  

  IpVersion vs Bool IpV4

  

  bool is no longer used to represnt IpVersion, the enum is used in tuple and

  anywhere else I spotted it.

  

  The result of this merge/cleanup has been regressed; I still need to re-write

  testTransportSelector.cxx.  The async model has not been used yet with the

  result of this merge, but it was used extensively in the branch.

  

  --Derek

  

  



------------------------------------------------------------------------------


  _______________________________________________
  resiprocate-devel mailing list
  resiprocate-devel at list.sipfoundry.org
  https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20050407/77fb903d/attachment.htm>