> As a goroutine may terminate if panic occurs If that happens, it will crash the entire program (go isn't python :-) https://go.dev/play/p/YD3lQ-xWe29
> I used recover() to log the error and the monitoring thread is re-created. But this doesn't help either. I noticed that the goroutine has been terminated but error hasn't been logged. How are you sure then, that the goroutine has terminated, not that it's just stuck? In any case, you shouldn't attempt to recover from a system-related panic (e.g. out of memory). The system will be in an invalid state; better let it crash and be restarted by some external supervisor. You can recover from an explicit panic() raised in your code, which is sometimes useful when unwinding the stack many levels, e.g. to terminate some deeply-nested recursive function, but that's something else. > Each sensor's state is maintained in sync.Map. The map maintains a pointer to the state. Whilst sync.Map protects against concurrent read/write access to the map itself, it doesn't protect against how you use that data. If you retrieve a pointer, and then read or write via that pointer from different goroutines, then you'll still need to protect those accesses with a mutex. It looks like you're doing this in the reading loop; we don't see the code which writes to the state. However, the go maxim is "share memory by communicating <https://go.dev/blog/codelab-share>". Could you arrange it so that your data collection process sends data down a channel, instead of updating shared memory? On Thursday, 26 January 2023 at 15:03:14 UTC [email protected] wrote: > I need to monitor the status of the N sensors and log it. I am creating a > separate goroutine for each sensor which fetches the state and logs it at > regular intervals. For each goroutine, a channel is created to read the > termination signal. Each sensor's state is maintained in sync.Map. The map > maintains a pointer to the state. Apart from monitoring goroutines, there > are processing goroutines that update the sensor's state. > > In my current implementation, the goroutines are able to log the status at > regular intervals. But after a few days, some goroutines stop logging the > status. But the processing goroutines are able to update the status. > > As a goroutine may terminate if panic occurs, I used recover() to log the > error and the monitoring thread is re-created. But this doesn't help > either. I noticed that the goroutine has been terminated but error hasn't > been logged. > > I suspect that because of memory leak, the goroutine might be terminated. > > Please find attached sample code. > > > It will be helpful if someone explains this abnormal behavior and provides > possible solutions. > Thanks > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e9da5e39-c664-4c52-aa4f-fded392b96f0n%40googlegroups.com.
