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

[derek]

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 <mailto:derek at xten.com>  

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/ad1d0a8e/attachment.htm>