set log function #3
Conversation
| github.com/mattn/go-pointer v0.0.1/go.mod h1:2zXcozF6qYGgmsG+SeTZz3oAbFLdD3OWqnUbNvJZAlc= | ||
| github.com/tinyzimmer/go-glib v0.0.24 h1:ktZZC22/9t88kGRgNEFV/SESgIWhGHE+q7Z7Qj++luw= | ||
| github.com/tinyzimmer/go-glib v0.0.24/go.mod h1:ltV0gO6xNFzZhsIRbFXv8RTq9NGoNT2dmAER4YmZfaM= | ||
| github.com/tinyzimmer/go-glib v0.0.25 h1:2GpumtkxA0wpXhCXP6D3ksb5pGMfo9WbhgLvEw8njK4= |
There was a problem hiding this comment.
We maintain out own fork of go-glib, so if you need something from v0.0.25, we'd need to make sure to import it into that fork
There was a problem hiding this comment.
egress replaces go-glib v0.0.25, seems like this project just hasn't been go mod tidy'd in a long time
gst/cgo_exports.go
Outdated
| message *C.GstDebugMessage, | ||
| _ C.gpointer, | ||
| ) { | ||
| if f := customLogFunction; f != nil { |
There was a problem hiding this comment.
I believe we also need to take the (RW?)Mutex here. Alternatively, an atomic.Pointer would work here too I believe, or even just documenting that SetLogFunction must be called first thing in main before any goroutine is started...
There was a problem hiding this comment.
that would be true if we were doing if customLogFunction != nil, but setting f creates a pointer to the function that won't be changed even if customLogFunction is modified during execution
There was a problem hiding this comment.
The issue here is that without some kind of synchronization/memory barrier, the go memory model (https://go.dev/ref/mem) does not guarantee that some goroutine will see the updated version of customLogFunction if SetLogFunction is called in another goroutine. Since you have a nil check, the consequence would be that the entry doesn't get logged, not a crash, so it may be an acceptable trade off?
There was a problem hiding this comment.
But in this case, you can also remove the call to logMu on the write side, as locking only on 1 side doesn't really make a difference.
No description provided.