Closed gizahNL closed 2 years ago
@iSchluff: you're quite involved in the non-blocking code, what do you think? I don't mind writing it myself, though a good implementation might not be that simple.
The basic idea is to mimic the golang polling server, and have calls that now directly call the epoll C function instead use the central polling server to poll for them while they block on a channel.
The prime motivation is performance: when a cgo call blocks, the go runtime detects this, and has to schedule a new OS thread, so limiting this to a minimum should reduce performance overhead when there are many SRT connections involved.
Fwiw: very much WIP work here: https://github.com/gizahNL/srtgo/tree/wip_pollserver
Yeah that's surely the way to go for making it more efficient. What are you referencing with golang polling server, is there a polling implementation in the standard library? I don't have much experience with cgo in general but I have written a polling app against the srtlib C-api before, so I guess I know what to expect.
Yeah that's surely the way to go for making it more efficient. What are you referencing with golang polling server, is there a polling implementation in the standard library? I don't have much experience with cgo in general but I have written a polling app against the srtlib C-api before, so I guess I know what to expect.
Iirc Golang does all IO "non-blocking" (it blocks the goroutine, not the OS thread), there is an implementation in the runtime called netpoll.
It would be nice if srtgo implemented a poll server (i.e. one dedicated thread to run the epoll function), as this would reduce cgo overhead significantly in cases where there are many srt connections that use non-blocking mode.