[reSIProcate] InviteSessionHandle and Multithreading

[Scott Godin]

If you need to check the state first, then you will need to create your own
commands.  The existing commands are limited in what they can do.

Scott

On Thu, Nov 17, 2016 at 8:40 AM, Diego Carvalho Domingos <
ddomingos at daitangroup.com> wrote:

> Hi all,
>
> I've already read the page about DUM threading and my application uses the
> Separate DUM and Stack Threads model. That page explains that in this case
> the application should queue commands to the DUM thread when it wants to
> call methods on the DUM API, and there are already available commands like
> provideOfferCommand, provideAnswerCommand and so on.
>
> My question is how can I use those commands if, before calling them, I
> have to make some checks using the InviteSessionHandle that I stored
> previously? (e.g isConnected, isAccepted, isTerminated). I think this
> wouldn’t be thread-safe.
>
> I could not find any examples in resiprocate code base that uses those
> commands. The dum tests answers directly from the callbacks, repro doesn't
> implement InviteSessionHandler callsbacks and recon creates its own
> commands. Should I create my own commands as well? If so, what are the use
> cases for the commands already provided by resiprocate? Thanks in advance.
>
>
>
> Diego
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20161118/09c24a4b/attachment.htm>