Data race with ServerForever and ServeNextRequest and Shutdown

[bb-raphaelp]

I have a problem with a data race in the GoSNMPServer during shutdown. This happens pretty reproducible in my test code.
Ideally the Shutdown method would interrupt the ServeNextRequest method before closing the udp connection.
Alternatively adding a context to ServeForever and/or ServeNextRequest to stop them via context close would enable me to work around this issue.

Relevant data race output:

==================
WARNING: DATA RACE
Read at 0x00c000012258 by goroutine 13:
  github.com/slayercat/GoSNMPServer.(*UDPListener).NextSnmp()
      /path/github.com/slayercat/!go!s!n!m!p!server@v0.5.0/interfaceListener.go:47 +0x6d
  github.com/slayercat/GoSNMPServer.(*SNMPServer).ServeNextRequest()
      /path/github.com/slayercat/!go!s!n!m!p!server@v0.5.0/snmpserver.go:81 +0xc1
  github.com/slayercat/GoSNMPServer.(*SNMPServer).ServeForever()
      /path/github.com/slayercat/!go!s!n!m!p!server@v0.5.0/snmpserver.go:54 +0x118
  [REDACTED]

Previous write at 0x00c000012258 by goroutine 9:
  github.com/slayercat/GoSNMPServer.(*UDPListener).Shutdown()
      /path/github.com/slayercat/!go!s!n!m!p!server@v0.5.0/interfaceListener.go:61 +0x51
  github.com/slayercat/GoSNMPServer.(*SNMPServer).Shutdown()
      /path/github.com/slayercat/!go!s!n!m!p!server@v0.5.0/snmpserver.go:44 +0x96
  [REDACTED]

[slayercat]

Thank you very much for bringing this issue to our attention. We greatly appreciate any help regarding this matter.

[charlysotelo]

I too ran into this issue and came up with #34

[slayercat]

Thank you very much for your interest in the project.
The issue of potentially ongoing activities during shutdown has indeed caught my attention. However, I believe that attempting to use locks during "acquisition" without considering the specific use cases does not adequately address this problem.
There are two viable approaches:

My personal preference is to implement lock-free reference counting during processing and wait during shutdown.
An alternative method could be to use read-write locks, allowing multiple simultaneous operations while permitting shutdown to occur in only one place. However, this approach would require simulation to determine if the implementation is reasonable and if the performance impact falls within acceptable limits.

I'm very much looking forward to discussing these aspects with you and conducting more test cases and simulations to confirm the feasibility of the relevant processes.
Once again, thank you for your interest in this matter.