Eliminate rare asynchronization bug in interpolator. #3260
Conversation
| TemporalId, Variables<typename InterpolationTargetTag:: | ||
| vars_to_interpolate_to_target>>*> | ||
| vars_dest_all_times) noexcept { | ||
| if (UNLIKELY(0 == vars_dest_all_times->count(temporal_id))) { |
There was a problem hiding this comment.
When testing a bit more last night, I found that we also need another similar check in have_data_at_all_points, because after the control flow exits this routine early, it will try to check if it needs to clean up the already cleaned-up temporal id.
| vars_dest_all_times) noexcept { | ||
| if (UNLIKELY(0 == vars_dest_all_times->count(temporal_id))) { | ||
| // vars_dest_all_times will almost always have an entry for | ||
| // temporal_id. This is because that entry is added by |
c83ee7a to
6eb8c4b
Compare
|
I completely re-did this PR. I put the checks elsewhere, so that |
moxcodes
left a comment
There was a problem hiding this comment.
Looks good -- I''ve used this patch for my latest runs and so far I haven't hit the problem again.
Thanks!
Proposed changes
See comments in code. This fixes a rare bug uncovered by @moxcodes , where
an InterpolationTarget can be finished with its work and can have already cleaned up,
but yet there are still elements sending data to that InterpolationTarget (where the data is
for points that are duplicated because they are on exactly the boundary between two or more elements).
Upgrade instructions
Code review checklist
make docto generate the documentation locally intoBUILD_DIR/docs/html.Then open
index.html.code review guide.
bugfixormajor new featureif appropriate.Further comments