You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
func (*Socket) Monitor ¶
func (soc *Socket) Monitor(addr string, events Event) error
Register a monitoring callback.
See: http://api.zeromq.org/4-1:zmq-socket-monitor#toc2
WARNING: Closing a context with a monitoring callback will lead to random crashes. This is a bug in the ZeroMQ library. The monitoring callback has the same context as the socket it was created for.
It would be helpful if the comment could be expanded to explain and give instructions on how to avoid random crashes.
Is the context an explicit Go context type, or does "context" mean the socket being monitored?
Does the developer need to call Close() on the PAIR monitor socket before calling Close() on the socket that is being monitored? (i.e. the problem occurs when the monitor socket is active but the socket being monitored is closed?)
Will the bug be triggered by runs of the example code, in which the monitor goroutine only exits the RecvEvent loop when RecvEvent returns err!=nil, or is the example code ok to use as a base for actual monitoring?
Is there an upstream reference for this bug? Or is it a "working as designed" issue, where developers are expected to write code in a certain way to not trigger a crash?
The text was updated successfully, but these errors were encountered:
Quote from https://pkg.go.dev/github.com/pebbe/zmq4 :
It would be helpful if the comment could be expanded to explain and give instructions on how to avoid random crashes.
Is the context an explicit Go context type, or does "context" mean the socket being monitored?
Does the developer need to call Close() on the PAIR monitor socket before calling Close() on the socket that is being monitored? (i.e. the problem occurs when the monitor socket is active but the socket being monitored is closed?)
Will the bug be triggered by runs of the example code, in which the monitor goroutine only exits the RecvEvent loop when RecvEvent returns err!=nil, or is the example code ok to use as a base for actual monitoring?
Is there an upstream reference for this bug? Or is it a "working as designed" issue, where developers are expected to write code in a certain way to not trigger a crash?
The text was updated successfully, but these errors were encountered: