Open ntquyen opened 7 years ago
is the Context often used as a container or something else?
Yes, it is used as a map to store header values and some request metrics
okay, uh, so the Context is commonly used as a single entity. well, we should use Mutex in our logic instead of directly bind a Mutex to the Contexts.
Should we orient ourselves toward context.Context? It is safe to use concurrently and gin.Context implements the interface.
any update on this issue?
As I just commented in pull request #702, putting a Mutex around c.Keys is a bad idea due to the recycling logic gin gonic applies to Context instances. You have to do a copy of the context (or of the Keys map) before sharing it, then handle the locking mechanism at your level.
Because of the recycling logic gin applies to Context, we can not simply use gin.Context and must do c.Copy for continue use(may be used in a goroutine), and this result that we do c.Copy nearly almost every method. Just thinking about we need an option to disable recycling logic for gin.Context.
Not sure if anyone started getting this issue with Go 1.8, but we did - a lot. (We just deployed to production with 1.8 for the first time today.)
Looks like 1.8 added a new check. From https://stackoverflow.com/questions/42453442/concurrent-map-iteration-and-map-write-error-in-golang-1-8 :
There is a enhanced concurrent access check added in the Golang 1.8, and this is the source code in runtime/hashmap.go:736,
if h.flags&hashWriting != 0 { throw("concurrent map iteration and map write") }
I'm trying to work around it right now, but I may be forced to toss a mutex lock into our vendor copy of Gin in the meantime (or roll back to 1.7)...
FYI This issue should be closed gin.Context
has a RWMutex
for safeguarding since v1.6.0
.
FYI This issue should be closed
gin.Context
has aRWMutex
for safeguarding sincev1.6.0
.
set header 、 set response , is it safe too?
I find this question @v1.4.0, question could go to sleep finally. Thx this issue.
I got a race condition when getting value from
Context
:concurrent map read and map write
The potential error code is in
/gin-gonic/gin/context.go
I thought here we must use Mutex around
c.Keys[key]
to avoid the race condition.