SRT API calls from the same OS thread

[curiousWanderer1982]

• Our application for receiving SRT flows is based on Golang and we use cgo to call into the SRT APIs (version 1.5.3) from a 'goroutine' (lightweight constructs being multiplexed onto OS threads).
• Based on its scheduling policies, the go runtime can schedule a goroutine on any of the available OS threads created for the process.

My question was whether it was ok to call the SRT APIs (like srt_recvmsg etc) potentially from a different OS thread each time, for performing operations on a given socket.

As a simplified example, assuming the application has 4 OS threads created (T1, T2, T3, T4) and a goroutine (G1), would the following sequence of calls to receive SRT payload work fine?

T1 --> srt_recvmsg (from G1)
// Go runtime 'moves' G1 to T2
T2 --> srt_recvmsg (from G1)
// Go runtime 'moves' G1 to T3
T3 --> srt_recvmsg (from G1)
// Go runtime 'moves' G1 to T4
T4 --> srt_recvmsg (from G1)

OR, would all the calls into the SRT APIs always need to happen from the same OS thread?

Something like:
T1 --> srt_recvmsg (from G1)
T1 --> srt_recvmsg (from G1)
T1 --> srt_recvmsg (from G1)
T1 --> srt_recvmsg (from G1)
where, goroutine G1 needs to be 'locked' to a single OS thread, like T1?

Thanks in advance!

[ethouris]

SRT is also using its own threads, so a single call to extracting a payload from the receiver buffer (ths srt_recv* call) is non-interruptible - for either another thread of SRT (the one to add a new packet to the buffer, for example) or another application thread that would like to call this function with the same socket. The calls done on different sockets don't even interfere with one another (except when using the same multiplexer, that is, if they are bound to the same host-port).

[curiousWanderer1982]

Thanks for clarifying that once a srt_recv* call is made from a given application thread (say, T1), it is non-interruptible and completes its execution before returning control to the caller. This aligns with our current usage of these APIs (i.e. no other application thread makes an API call for the same socket, while a current one is in progress).

For our use case, wanted to confirm that it was also OK for a subsequent srt_recv* call to be made potentially by a different application thread (say T2) and that the SRT library internally had no thread-local state (attached to the previous call made from T1) that would expect the srt_recv* API calls to be always made from the same application thread (T1) each time?

Thanks!