reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

[reSIProcate] 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@xxxxxxxxxxxxx]
Sent: Thursday, April 07, 2005 2:29 AM
To: derek
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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

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@xxxxxxxxxxxxxxxxxxx
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.