modules/mixer: update T tap once in prepare_frame

It's problematic/racy to always be dereferencing the tap pointer
to access it's current value.

Running checkers:fill_module=mixer on a 2c/4t (n_cpus=4) machine
was quite effective at crashing in mixer::render_fragment()
due to dereferencing a NULL snapshot fragment.

The "tween" T value is being used to indicate when interpolation
of the snapshots is necessary.  But repeatedly re-reading the T
value via the tap pointer would race with the driving tap.  In
the case of checkers, which is a threaded module, the mixer
contexts are all rendering in parallel at the same path so
they're sharing a single pipe for their T taps.

This situation of sets of contexts sharing a single path,
resulting in their taps all landing on a single pipe, is still
largely up in the air and might be actively prevented in the
future.  But until then, it can be made far less crashy and
problematic by just being more careful about dereferencing the
tap to access its latest value just once at the prepare frame
stage, storing it in the local T variable in the context.  Then
all the render_fragment() accesses can at least find a stable
value in the context from prepare-to-render, so at least the
snapshots are there when they should be according to the T value
etc.

Something like this will probably need to be done regardless of
what happens with the context sets sharing the same path.  Since
when a given tap isn't the driver, it still has to take care to
just grab the updated value once for the frame...  The tap API
can't really automagically do that single update of the local
variable when passenger though, since it's been deliberately kept
devoid of all the type-specific accessor junk (ptr/elems etc are
all void **/void* in the tap api side).  Hence why this commit is
just ad-hoc updating the local variable in the else branch; it's
best positioned to do so directly.  But there still needs to be
more consideration for thread-safety.

0 files changed, 0 insertions, 0 deletions