| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
|
In fact I am writing a
communication library that wraps recon and offers a number of services to the
application. That library exposes also a process() method that invokes by its
turn UserAgent::process() So the “process
loop” is realized in the application code. That library invokes
callbacks on the application. The application
developer is asking me the following question: - In a callback from
my library (originated from UserAgent::onFailure()) the application code issues
a Windows modal popup that blocks the proceeding of the callback and so, the
proceeding of the UserAgent::process() invocation that originated the callback. - But the developer
wants, while the first callback is blocked, to make other invocations on
process() to allow for receive callbacks derived from UserAgent::onSuccess()
when network conditions allowed succesful SIP registration. I advised him not to
use process() this way (reentrantly) but he would like to know by sure if that
kind of reentrancy in recon is definitely disallowed or not. Julio. > The thread safety aspects of recon, rely on the fact that process is
called from one thread only. What are you trying to accomplish by
using two process loops? > >
Scott > On Mon, Jun 1, 2009 at 7:41 PM, Julio Cabezas <jcabezas@xxxxxxxxxxxxx> wrote: > Hi. >
I am using recon in a softphone project. > At a certain point I
decided to make a try of using UserAgent::process() reentrantly: i.e. an
instance of that function invocation before the return of previous invocations.
I found undesirable behaviors by doing that. > What can
be stated with certainty about the possibility of reentrancy in the use of
recon and DUM ? > Best Regards, > Julio Cabezas. |