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

RE: [reSIProcate] dum callback model design


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@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Meir Elberg
Sent: Thursday, October 27, 2005 7:06 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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.