[reSIProcate] dum callback model design

[Scott Godin]

You approach sounds fine to me.  Perhaps you do not need to post events
for all of DUM's callbacks.  Some callbacks (such as the two you
mentioned) likely do not need to do work that requires time (ie. access
network entities).

 

Scott

 

________________________________

From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of Meir
Elberg
Sent: Thursday, October 27, 2005 7:06 AM
To: resiprocate-devel at list.sipfoundry.org
Subject: [reSIProcate] dum callback model design

 

Hi,

I'm designing a B2B using the DUM. This B2B has to access to network
entities and sometime would have to make relatively long processing. To
prevent DUM stack from hanging  we use application threads that access
these network entities and do the processing.

We implement the DUM callbacks to post events to the application
threads. When an application thread completes its processing it post DUM
Commands to perform the operation on the relevant handle on the DUM
stuck. 

Currently almost all of the callbacks return no value and therefore the
actual processing of the callback can be performed asynchronously. 
However, there are two callbacks that expect a return value and cannot
work in such a model:
virtual int
ClientRegistrationHandler::onRequestRetry(ClientRegistrationHandle, int
retrySeconds, const SipMessage& response)=0; 
virtual bool RedirectHandler::onTryingNextTarget(AppDialogSetHandle,
const SipMessage& request)=0; 

This is the best method we found to separate the DUM stack thread from
the application threads.
These two exceptions prevent the model from working as a concept. do you
think we can rely on this concept for the future ?

I would be glad to have your opinion regarding that.
Please advise.

Thanks,
Elberg Meir.
Ventego Networks.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20051027/d361c329/attachment.htm>