5 ms·
If you are accessing variables declared outside the http server, and you use any non-thread safe types or code it will panic. For instance, try and read a map,
by dana321 7y ago
If you are accessing variables declared outside the http server, and you use any non-thread safe types or code it will panic.
For instance, try and read a map, it will crash your code.
It won't show this as a problem until you have real traffic on your service.. Hitting it in your browser isn't enough to test properly.
- tedunangst 7y agoMaps are concurrent readonly safe.
- dana321 7y agoThey aren't safe to read or write concurrently.
- palebluedot 7y ago> They aren't safe to read or write concurrently. Slightly ambiguous wording, so just to clarify: Go maps are safe to read concurrently Go maps are not safe to read AND write concurrently Go maps are not safe to write concurrently
- dana321 7y agoBoth!!! Its out there, in the wide world for everyone to read, just use Google!!
- palebluedot 7y agoI wasn't asking a question, I was clarifying.
- erik_seaberg 7y agoYou can't declare a read-only map (or slice). Actually Java made exactly the same mistake, the best you can do is to implement Map<K, V> and List<T> with setters that throw at runtime.
- pianoben 7y agoSo, accessing shared mutable state from many threads at once is dangerous. It's hard to lay the blame for this on Go - it's true in most languages I know of. I suppose one ought to guard such maps with a RW lock, or a `sync.Map` which is tailor-made for this kind of situation.
- dana321 7y agosync.Map is slower than searching a slice of k-v struct for roughly <1000 elements. Go designed their map implementation to be unsafe for both read and write. I kind of don't care, i was trying to point out something simple and everyone is nitpicking.