You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
gin.Context implements context.Context. In my opinion, it should follows context.Context package's thread safety guaranties.
However gin doc states, that gin.Context is valid only in a request scope. And one should call Copy to avoid pitfalls.
Copy returns a copy of the current context that can be safely used outside the request's scope. This has to be used when the context has to be passed to a goroutine.
This should work according to the documentation and general expectations. However, with ContextWithFallback we would get following result on context cancellation:
I won't dive deeply into reasoning. Default http library leaks context to other gorouting outside of request scope. The main problem is that programmer shouldn't know implementation details of http lib! It should just work!
Consider other example in the code below. Most of the time we can't even call Copy in some deep nested code.
So, now the only way of safe usage of gin.Context is to call Copy on every conversion to the context.Context. But this makes the whole point of implementing context.Context useless.
But even this is not always possible in middleware/generated code world. So we are abandoning usage of gin in out tech stack.
But I hope this will help to improve gin, as it is truly good http framework.
My proposals:
Either disable context pooling when ContextWithFallback is enabled.
Or stop implementing context.Context and provide explicit GetContext/MakeContext methods, that will return threadsafe context. As this is the breaking change, consider it for gin/v2
sync.Pool is not a cache in the true sense. It might be more appropriate to call it a "recycle bin". The data put into it is logically considered to have been deleted, but physically, the data still exists. This data can survive for two rounds of garbage collection time. i tested the code and i guess this will fail in high concurrency situation?
it seems that one goroutine has finished and the other get the same context and want to set sth, but if the routine has finished it should has returned the context to the pool so that the next can get the context
Description
gin.Context
implementscontext.Context
. In my opinion, it should follows context.Context package's thread safety guaranties.However gin doc states, that
gin.Context
is valid only in a request scope. And one should callCopy
to avoid pitfalls.But consider following example.
This should work according to the documentation and general expectations. However, with
ContextWithFallback
we would get following result on context cancellation:I won't dive deeply into reasoning. Default http library leaks context to other gorouting outside of request scope. The main problem is that programmer shouldn't know implementation details of http lib! It should just work!
Consider other example in the code below. Most of the time we can't even call
Copy
in some deep nested code.So, now the only way of safe usage of
gin.Context
is to callCopy
on every conversion to thecontext.Context
. But this makes the whole point of implementingcontext.Context
useless.But even this is not always possible in middleware/generated code world. So we are abandoning usage of gin in out tech stack.
But I hope this will help to improve gin, as it is truly good http framework.
My proposals:
context.Context
and provide explicitGetContext/MakeContext
methods, that will return threadsafe context. As this is the breaking change, consider it for gin/v2How to reproduce
go test -race -bench=.
Expectations
Just works
Actual result
DATA RACE as above
Environment
The text was updated successfully, but these errors were encountered: