Re: [reSIProcate] InviteSessionHandle and Multithreading

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

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.

Scott

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?

 

Scott

 

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@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@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@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel