gobuffalo/envy

potential race condition using envy.Temp

Closed this issue · 2 comments

There appears to be a potential race condition using envy.Temp. Since it does not have any kind of lock associated with it using it with goroutines could cause problems I think. Perhaps it should have it's own lock? (I guess it can't use gil because then it would deadlock with any Set methods called in the callback)

On more or less the same topic, this also seems weird

// Map all of the keys/values set in envy.
func Map() map[string]string {
	gil.Lock()
	defer gil.Unlock()
	return env
}

The mutex will be released before the map is returned to the caller so I'm not sure how much it helps here. It would block a goroutine acquiring the map while it was locked by another function but since it's released when the function exits there's no way to stop the map being read or altered at the same time as another goroutine is modifying it. Since the library makes the effort to wrap the map up with a mutex it seems strange to then just hand it out like this. Maybe Map should be returning a copy, although I guess that would need a major version release since it could break a bunch of code.

Fixed with #14.