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
In #485 a mutex has been added to FieldMap to make it Thread Safe.
However, in the same PR, the Message pool mechanism has also been removed so Messages are not re-used any longer and it's up to the Go garbage collector to free unused messages.
In that context I fail to see a scenario where a Message and the underlying FieldMaps need to be thread safe.
Can someone share a use case where a message is concurrently read/updated ?
I was asking myself the same question. We got bitten by slow reads from parsed message since every field is protected mutex lock slowing down the processing.
I would prefer no locking of messages especially if they are no longer reused.
If you need to lock the FieldMap you should do it outside in your own code (this would also improve when getting or setting multiple fields).
In #485 a mutex has been added to FieldMap to make it Thread Safe.
However, in the same PR, the Message pool mechanism has also been removed so Messages are not re-used any longer and it's up to the Go garbage collector to free unused messages.
In that context I fail to see a scenario where a Message and the underlying FieldMaps need to be thread safe.
Can someone share a use case where a message is concurrently read/updated ?
cc @waheedoo @ackleymi
The text was updated successfully, but these errors were encountered: