diff options
author | Jesse Hallam <jesse.hallam@gmail.com> | 2018-04-13 20:09:38 -0400 |
---|---|---|
committer | Derrick Anderson <derrick@andersonwebstudio.com> | 2018-04-13 20:09:38 -0400 |
commit | 8056dc33e31d87ff81d286b9991883f953705f15 (patch) | |
tree | 1ec8e3290d979d2aa25a0e0d0f437b779d1d3e50 /scripts | |
parent | a7fd13384b3f147d9b482fc43f886f747704134c (diff) | |
download | chat-8056dc33e31d87ff81d286b9991883f953705f15.tar.gz chat-8056dc33e31d87ff81d286b9991883f953705f15.tar.bz2 chat-8056dc33e31d87ff81d286b9991883f953705f15.zip |
Prevent disabling or modifying l4g logging filters (#8628)
The underlying l4g library is not resilient to filter modifications in
the presence of concurrent goroutines. In particular, it's not safe to
call Close() on filters which might be actively held by a goroutine for
logging.
This change disables all modifications to existing filters once
initialized by the App layer. In practice, we might be able to get away
with some modifications to the existing filters (i.e. changing levels),
but the [golang memory model](https://golang.org/ref/mem) makes no
guarantees that it is safe to do so:
> Programs that modify data being simultaneously accessed by multiple goroutines must serialize such access.
We can solve this holistically by introducing the requisite locking
within our fork of the l4g library. For now, we just disable all
modifications.
Diffstat (limited to 'scripts')
0 files changed, 0 insertions, 0 deletions