The rationale for why regenerateMembersCache didn't need to hold the Lock() throughout was subtly wrong. It is true that at least some attempt to regenerate the cache would see *all* the updates. However, it was possible for the value of `result` generated by that attempt to lose the race for the final assignment `channel.membersCache = result`. The fix is to serialize the attempts to regenerate the cache, without adding any additional locking on the underlying `Channel` fields via `Channel.stateMutex`. This ensures that the final read from `Channel.members` is paired with the final write to `Channel.membersCache`.tags/v0.10.1
|
|
||
19 |
|
19 |
|
20 |
|
20 |
|
21 |
|
21 |
|
22 |
|
|
|
23 |
|
|
|
24 |
|
|
|
25 |
|
|
|
26 |
|
|
|
27 |
|
|
|
28 |
|
|
|
29 |
|
|
|
30 |
|
|
|
31 |
|
|
|
32 |
|
|
|
33 |
|
|
|
34 |
|
|
|
35 |
|
|
|
|
22 |
|
|
|
23 |
|
|
|
24 |
|
|
|
25 |
|
|
|
26 |
|
|
|
27 |
|
|
|
28 |
|
|
|
29 |
|
|
|
30 |
|
|
|
31 |
|
|
|
32 |
|
|
|
33 |
|
|
|
34 |
|
|
|
35 |
|
|
|
36 |
|
|
36 |
|
37 |
|
37 |
|
38 |
|
38 |
|
39 |
|
|
|
||
67 |
|
68 |
|
68 |
|
69 |
|
69 |
|
70 |
|
70 |
|
|
|
|
71 |
|
|
71 |
|
72 |
|
72 |
|
73 |
|
73 |
|
|
|
|
74 |
|
|
|
75 |
|
|
|
76 |
|
|
|
77 |
|
|
|
78 |
|
|
|
79 |
|
|
74 |
|
80 |
|
75 |
|
81 |
|
76 |
|
82 |
|