-
Notifications
You must be signed in to change notification settings - Fork 5
Description
I hope I am not creating clutter with this.
I think there is the potential for a race condition when a job is started at the same time that Shutdown(...) is called for the in memory store.
When shutdown is called it reads the context array without a mutex, which would be in a different go routine than the workers themselves that own the context. A context could be appended to this array while shutdown is being performed.
neoq/backends/memory/memory_backend.go
Lines 193 to 199 in a17ea73
| func (m *MemBackend) Shutdown(ctx context.Context) { | |
| for _, f := range m.cancelFuncs { | |
| f() | |
| } | |
| m.cancelFuncs = nil | |
| } |
But a mutex is used when the contexts are added.
neoq/backends/memory/memory_backend.go
Lines 139 to 141 in a17ea73
| m.mu.Lock() | |
| m.cancelFuncs = append(m.cancelFuncs, cancel) | |
| m.mu.Unlock() |
- I think the mutex should be changed to a RWMutex with Shutdown acquiring a read lock on the array, and start acquiring a write lock on the array. This would prevent start from adding a new context and thus starting a new job during a shutdown. But does not prevent a job from starting immediately afterwards.
- Do the contexts ever get cleaned up from this array? I don't see anything immediately that would remove items from the array after a job has completed. While I doubt these are of significant overhead would it be worth looking into a way to clean them up afterwards as well?
Happy to take on this work myself and contribute, really excited to start using this tool!