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.