Fix context keys get set

[rohan-j-shah]

Fix for : fatal error: concurrent map read and map write

[coveralls]

Coverage increased (+0.01%) to 94.099% when pulling 5a6b31c on goibibo:fix_context_keys_get_set into f931d1e on gin-gonic:develop.

[cookingkode]

I would suggest taking it before nil check to avoid a set being lost..

[coveralls]

Coverage increased (+0.01%) to 94.099% when pulling 9ab71be on goibibo:fix_context_keys_get_set into f931d1e on gin-gonic:develop.

[coveralls]

Coverage increased (+0.01%) to 94.099% when pulling 9ab71be on goibibo:fix_context_keys_get_set into f931d1e on gin-gonic:develop.

[coveralls]

Coverage increased (+0.01%) to 94.099% when pulling 9ab71be on goibibo:fix_context_keys_get_set into f931d1e on gin-gonic:develop.

[coveralls]

Coverage increased (+0.01%) to 94.099% when pulling 8c413be on goibibo:fix_context_keys_get_set into f931d1e on gin-gonic:develop.

[tboerger]

Please rebase correctly, than you can get some proper review.

[maxatome]

The locking mechanism involved in this pull request is not needed as the original gin.Context should not be used outside the original gin gonic goroutine without copying it (Copy method). In fact, it even hides some biggest errors!
If you have a "concurrent map read and map write" error, it means that you did a mistake. Probably using the same context in different goroutines without copying it.
If you need to share a gin.Context between several goroutines of your own, you first have to copy (Copy method) it then handle the locking mechanism yourself at your level, perhaps by composing the gin.Context in your own struct.
The problem with your patch is that it hides completely the fact that gin.Context instances are reused once the request is handled at the gin gonic level.

[tsirolnik]

@maxatome I'm not sharing the context but I still do get panics sometimes even though the key was set.

See this issue #836

[thinkerou]

@rohan-j-shah please re-commit the pull request to master branch, thanks!

[thinkerou]

closing, ref #1391