It is quite easy to get this panic in case somehow FreeSubscribe function is called, while doLoopSubscribe is still in the middle of the innermost loop:
goroutine 49 [running]:
github.com/jhunters/bigqueue.(FileQueue).doLoopSubscribe(0xc0000b6370)
/Users/nickgolikov/go/pkg/mod/github.com/jhunters/bigqueue@v1.2.2/filequeue.go:805 +0x54
created by github.com/jhunters/bigqueue.(FileQueue).Subscribe
/Users/nickgolikov/go/pkg/mod/github.com/jhunters/bigqueue@v1.2.2/filequeue.go:775 +0x70
Which can happen in case the processing function, added in Subscribe, has any blocking logic with channels, for example, and the FreeSubscribe is called in some other routine.
Or if the FreeSubscribe is called in the subscribed function itself (I added the test purely for demonstration purposes, prior to proposed changes that test would trigger a panic).
It is quite easy to get this panic in case somehow FreeSubscribe function is called, while doLoopSubscribe is still in the middle of the innermost loop:
Which can happen in case the processing function, added in Subscribe, has any blocking logic with channels, for example, and the FreeSubscribe is called in some other routine. Or if the FreeSubscribe is called in the subscribed function itself (I added the test purely for demonstration purposes, prior to proposed changes that test would trigger a panic).