When I first created this topic I was talking about InviteSession’s commands but now I was talking specifically about DialogUsageManager::sendCommand.
Thanks for all the explanations, Scott and Dario. If possible, add an entry in resiprocate’s TODO list to update the DUM threading page. Thanks in advance. Regards,
Diego
From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx]
On Behalf Of Scott Godin
Sent: terça-feira, 31 de janeiro de 2017 12:17
To: Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx>
Cc: Dario Bozzali <Dario.Bozzali@xxxxxxxxxxx>; resiprocate-devel@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] InviteSessionHandle and Multithreading
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.
On Tue, Jan 31, 2017 at 8:06 AM, Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx> 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
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@xxxxxxxxxxxxxxx]
On Behalf Of Scott Godin
Sent: lunedì 30 gennaio 2017 21.29
To: Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx>;
resiprocate-devel@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx> 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.
On Mon, Jan 30, 2017 at 3:05 PM, Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx> 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@xxxxxxxxx [mailto:slgodin@xxxxxxxxx]
On Behalf Of Scott Godin
Sent: segunda-feira, 30 de janeiro de 2017 17:36
To: Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx>
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?
On Mon, Jan 30, 2017 at 2:12 PM, Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx> 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@xxxxxxxxx [mailto:slgodin@xxxxxxxxx]
On Behalf Of Scott Godin
Sent: sexta-feira, 18 de novembro de 2016 12:31
To: Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx>
Cc: resiprocate-devel@xxxxxxxxxxxxxxx
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.
On Thu, Nov 17, 2016 at 8:40 AM, Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
|