[reSIProcate] InviteSessionHandle and Multithreading

Tue Jan 31 08:17:23 CST 2017

Hi Diego,

When you were saying sendCommand - I thought you meant the built in command
in the InviteSession objects (ie: provideOfferCommand) - I didn't even
realize that was an API on the DUM object.  Now that I look it, I
understand what you are saying.

Dario - excellent point about makeUACDialogSet - that is definitely not
thread safe.

So the conclusion is.... makeXXXXX API's are NOT threadsafe.

Scott

On Tue, Jan 31, 2017 at 8:06 AM, Diego Carvalho Domingos <
ddomingos at daitangroup.com> wrote:

> Hi everyone,
> Thanks for participating in this discussion. My point is that, if calling
> makeXXXX is not thread safe, there is no use case for sendCommand, since
> the code would need to be already executing in the DUM thread to create the
> message to be sent. And my goal here is to get the DUM threading page
> updated to be more clear about these important details, specially
> explaining the situations where using the commands provided by resiprocate
> is possible (and when you should create your own commands). Regards,
>
> Diego
>
>
>
> *From:* Dario Bozzali [mailto:Dario.Bozzali at ifmgroup.it]
> *Sent:* terça-feira, 31 de janeiro de 2017 06:42
> *To:* Scott Godin <sgodin at sipspectrum.com>
> *Cc:* Diego Carvalho Domingos <ddomingos at daitangroup.com>;
> resiprocate-devel at resiprocate.org
> *Subject:* RE: [reSIProcate] InviteSessionHandle and Multithreading
>
>
>
> Hi Scott,
>
> I was not aware of the issue. I invoke makeXXXX APIs in the same thread that I use to process DUM events. I use sync commands on DUM objects in that thread instead of using DumCommands (i.e. end() instead of InviteSessionEndCommand, or send() instead of SendCommand).
>
> I think that your proposed solution (invoke makeXXXX API in DUM thread)
> could be acceptable. I have a couple of questions about it anyway. In this
> case we can use either send() or SendCommand, right? If we want to invoke
> makeXXXX API in DUM thread (and application thread is not used to process
> DUM events like in my application), do we need to use custom DUM command?
>
> One last question. Diego told “calling makeRegistration, makeSubscription and makeOutOfDialogRequest from the application thread and use sendCommand would not be a problem then”. Since all that methods invoke DialogUsageManager::makeUacDialogSet(), we have the issue for any of the makeXXXX API, right?
>
> Thank you and best regards,
>
> Dario
>
>
>
> *From:* resiprocate-devel [mailto:resiprocate-devel-
> bounces at resiprocate.org <resiprocate-devel-bounces at resiprocate.org>] *On
> Behalf Of *Scott Godin
> *Sent:* lunedì 30 gennaio 2017 21.29
> *To:* Diego Carvalho Domingos <ddomingos at daitangroup.com>;
> resiprocate-devel at resiprocate.org
> *Subject:* Re: [reSIProcate] InviteSessionHandle and Multithreading
>
>
>
> Hi Dev Team,
>
>
>
> Just a sanity check, here.  I was under the impression that the DUM
> makeXXXX API's were thread safe from outside the dum thread.  However it
> appears that if you supply an AppDialogSet to these API's, then the handle
> map can be adjusted (no locks) outside the DUM thread when creating the
> AppDialogSet.  Was anyone else aware of this oversight?  Any immediate
> thoughts on a solution, other than to force an application to call the
> makeXXXX API's from DUM thread when an AppDialogSet is required?
>
>
>
> Scott
>
>
>
> On Mon, Jan 30, 2017 at 3:25 PM, Scott Godin <sgodin at sipspectrum.com>
> wrote:
>
> I agree the DUM threading page could use some pointers to the existing
> DumCommands that exist.  Those were added after that page was created, so
> they are missing.
>
>
>
> I didn't analyze it in detail, but I believe you are correct that in
> general calling the makeXXXX api's is thread safe.  As long as you don't
> need to create an AppDialogSet to pass to them.
>
>
>
> In fact this AppDialogSet issue has got me thinking that we really need
> some solution to this issue, since I believe the original intent was for
> the all makeXXXX DUM API's to be thread safe.
>
>
>
> Thanks for your feedback.
>
>
>
> Scott
>
>
>
> On Mon, Jan 30, 2017 at 3:05 PM, Diego Carvalho Domingos <
> ddomingos at daitangroup.com> wrote:
>
> Thanks for the quick reply.
> Probably yes. I couldn’t confirm that the entry was added by
> makeInviteSession. I just added some logs to HandleManager and noticed
> that the entry was being added before the call to sendCommand, which is a
> problem. But we do need to create a AppDialogSet to pass it to
> makeInviteSession, so probably that’s the place which is adding the entry,
> like you said. So if I didn’t had to create a AppDialogSet I think I
> wouldn’t have this issue.
>
> My point is that it is not clear which method you can or cannot call from
> you application thread and the presence of these commands made me think
> that using them would make my application thread safe, so it is a little
> confusing and I could not find any example using those commands…So, in my
> opinion, that page that explain DUM threading should emphasize that using
> the available commands is almost never (sorry, but as I explained I could
> not find any example for them) an option and you should create your own
> commands. Anyway, thanks for explaining the problem.
>
> Another related question: based on your explanation, calling
> makeRegistration, makeSubscription and makeOutOfDialogRequest from the
> application thread and use sendCommand would not be a problem then, right?
> Thanks a lot again,
>
>
>
> Diego
>
>
>
> *From:* slgodin at gmail.com [mailto:slgodin at gmail.com] *On Behalf Of *Scott
> Godin
> *Sent:* segunda-feira, 30 de janeiro de 2017 17:36
> *To:* Diego Carvalho Domingos <ddomingos at daitangroup.com>
>
> *Subject:* Re: [reSIProcate] InviteSessionHandle and Multithreading
>
>
>
> Hi Diego,
>
>
>
> I'm having trouble following the issues you were having.  I'm pretty sure
> makeInviteSession doesn't add an entry to the HandleManager's map until a
> response arrives.  Can you help me, and point out the line of code that
> does this?
>
>
>
> As for the commands that exist today.  They allow you to preform *some* of
> the DUM operations in a thread safe manner from a non-DUM thread.
>
>
>
> That all being said - I noticed that creating an AppDialogSet from the
> application thread, will end up inserting a record into the HandleManager's
> map and this could be dangerous.  Is this perhaps what you were seeing?
>
>
>
> Scott
>
>
>
> On Mon, Jan 30, 2017 at 2:12 PM, Diego Carvalho Domingos <
> ddomingos at daitangroup.com> wrote:
>
> Hi Scott,
> I would like to bring this topic back because I thought I have managed to
> make my application thread safe but then I got a core in
> HandleManager::getHandled. Later I discovered that the problem was that
> makeInviteSession adds an entry to HandleManager’s internal map and I had
> thought that calling it in my application thread an then using sendCommand
> to send the message on the DUM thread would be safe but it isn’t. So what
> are the use cases for these commands provided by resiprocate, specially
> sendCommand, if you need to be already executing on the DUM thread to call
> makeXXX methods? Regards,
>
>
>
> Diego
>
>
>
> *From:* slgodin at gmail.com [mailto:slgodin at gmail.com] *On Behalf Of *Scott
> Godin
> *Sent:* sexta-feira, 18 de novembro de 2016 12:31
> *To:* Diego Carvalho Domingos <ddomingos at daitangroup.com>
> *Cc:* resiprocate-devel at resiprocate.org
> *Subject:* Re: [reSIProcate] InviteSessionHandle and Multithreading
>
>
>
> 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/20170131/568b9bde/attachment.htm>