Using SendMsgCmd from multiple Go routines concurrently about fsock HOT 3 CLOSED

Hey Tom,

Well we do not lock anything on writing over self.conn, however for this
concurrent access style would recommend using FSockPool type since that
is able to raise connections as you need them. Not sure if locking
self.conn would help in cases when there it takes a long time to
FreeSWITCH to answer (eg: call originate command).

Let me know how you see it.

Thanks,
DanB

from fsock.

Btw, this is an example of how we use the pool (after int with New...):

"""
fsConn, err := PopFsConn()
if err != nil {
return err
} else {
defer PushFsConn(fsConn)
}
if _, err := fsConn.SendApiCmd(cmdStr); err != nil {
return err
}
"""

DanB

On 03.06.2014 13:11, TomP wrote:

Hi,

I'm not sure if this an issue or not, more of a discussion.

If register an event handler that is called multiple times
concurrently (for example from multiple calls) and that event requires
that I generate a 'response' back to Freeswitch using the SendMsgCmd()
function.

My event handlers have access to the FSock pointer variable, so can
call SendMsgCmd() from inside their event handler Go routine.

If multiple Go routines call SendMsgCmd() at the same time, do the
response get muddled, or does SendMsgCmd() lock self.conn before
writing to it?

—
Reply to this email directly or view it on GitHub
#3.

from fsock.

Thanks Dan, much appreciated will go that route.

from fsock.