[reSIProcate] dum callback model design

[Alan Hawrylyshen]

Scott;

I can imagine scenarios that require expensive (timewise) resource  
allocation on these callbacks. I think this might be a real issue for  
using DUM in this application. Do any of the DUMber folks have an  
opinion on this? :-)

Alan

On 27-Oct-05, at 06:39 , Scott Godin wrote:

> 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.
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

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