Solution: keep goroutine running to allow graceful shutdown
Currently if any error is returned by ZMQ calls made inside the Channeler actor goroutine it triggers an immediate exit of the that goroutine. This makes it impossible to shut down the companion channeler goroutine (and allow it to free its allocated resources) because the only path for doing so is sending "destroy" to commandChan which then causes the channeler goroutine to block forever waiting for a response to the "destroy" command from a now missing actor goroutine here: https://github.com/zeromq/goczmq/blob/4dc887d7239b715e613e2937d5aaf58d2033c8b0/channeler.go#L205
The proposed solution keeps the actor goroutine working and hopefully able to receive and process the "destroy" command even after returning an error. Presuming whatever error it received doesn't also prevent that from happening.
I've tested the change manually using pub/sub scripts from https://github.com/zeromq/goczmq/pull/285 and by adding randomly returned errors to the relevant methods as I'm unaware of another way to make those functions return an error on demand.
To illustrate the issue, without the fix, if an error is returned from poller.Wait and the application then calls Destroy it results in this goroutine staying around:
Solution: keep goroutine running to allow graceful shutdown
Currently if any error is returned by ZMQ calls made inside the Channeler
actorgoroutine it triggers an immediate exit of the that goroutine. This makes it impossible to shut down the companionchannelergoroutine (and allow it to free its allocated resources) because the only path for doing so is sending"destroy"tocommandChanwhich then causes thechannelergoroutine to block forever waiting for a response to the "destroy" command from a now missingactorgoroutine here: https://github.com/zeromq/goczmq/blob/4dc887d7239b715e613e2937d5aaf58d2033c8b0/channeler.go#L205The proposed solution keeps the
actorgoroutine working and hopefully able to receive and process the"destroy"command even after returning an error. Presuming whatever error it received doesn't also prevent that from happening.I've tested the change manually using pub/sub scripts from https://github.com/zeromq/goczmq/pull/285 and by adding randomly returned errors to the relevant methods as I'm unaware of another way to make those functions return an error on demand.
To illustrate the issue, without the fix, if an error is returned from
poller.Waitand the application then callsDestroyit results in this goroutine staying around: