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
|