[reSIProcate] Re: Alternative "async/external" Processing Model

Fri Apr 8 09:03:44 CDT 2005

If I well unterstood, the DumProcessHandler is usefull only in a architecture based on DUM/Stack in the same thread
and Transport in separate threads ?

What I am searching for is a mean to have a Call Back called each time an event is posted to the TUFifo when the Stack
and Transport run in different threads than the DUM application.
In this Call Back I could signalled a system event that will wake up my DUM thread which is blocked on multiple event object.
Thus on wake up, the DUM thread know it must call procces() method to process a new event in its Fifo.
Is it possible to do that with the TuSelector ?
It doesn't seem possible at that time, but if ever we add a virtual method to TransactionUser class that is called
after each msg post in TUFifo, could it be solved my problem ?

I'm a newbie in using resiprocate, so perhaps I am missunderstood some concept about the management of DUM
event management, so just tell me. Thanks

Julien

  ----- Original Message -----
  From: derek
  To: 'Bellanger Julien'
  Cc: resiprocate-devel at list.sipfoundry.org
  Sent: Thursday, April 07, 2005 5:33 PM
  Subject: RE: Alternative "async/external" Processing Model

  The DumProcessHandler doesn't poll the SipStack; no timers are sent when there isn't outstanding work to be done.  It will be refactored wrt to TuSelectors, but it was designed to fit DUM/resip into a certain set of architectural constraints and was not designed to be threadsafe.

  --Derek

  CONFIDENTIALITY NOTICE

  This email and any files transmitted with it contains proprietary information and, unless expressly stated otherwise, all contents and attachments are confidential. This email is intended for the addressee(s) only and access by anyone else is unauthorized. If you are not an addressee, any disclosure, distribution, printing or copying of the contents of this email or its attachments, or any action taken in reliance on it, is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately and then delete this email and any copies of it. Thank you for your co-operation.

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

  From: Bellanger Julien [mailto:julien.bellanger at capgemini.com]
  Sent: Thursday, April 07, 2005 2:29 AM
  To: derek
  Cc: resiprocate-devel at list.sipfoundry.org
  Subject: Alternative "async/external" Processing Model

  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.

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/20050408/94f00b90/attachment.htm>