Consider expert interfaces for writing to data in place

[HadrienG2]

As pointed out by users.rust-lang.org member fyl2xp1 in a thread about his own implementation of triple buffering, it would be nice in some cases if the producer and the consumer could overwrite their buffer, as some copies could sometimes be avoided that way.

I historically considered this option while writing triple-buffer, but ultimately decided against it at the time because it exposed some confusing aspects of the synchronization protocol to the clients:

• The producer ends up with a buffer that basically contains stale data that it wrote a long time ago, and must be very careful not to confuse this with any data that it has freshly sent (which is kept away from its reach so that the consumer can safely access it).
• Both the producer and the consumer can have, by design, their buffer transparently swapped under their feet whenever they are not looking at it. It is thus not a very safe place to store data, unless some long-lived references are used to prevent swapping.
• But long-lived mutable references have unpleasant ergonomics in Rust. Moreover, in the producer case, the data must be swapped at some point to make it available to the reader anyhow, so the long-lived reference should maybe be some kind of RAII guard that ensures that the buffer is swapped when its reference goes out of scope... Again, it can get confusing quickly.

If there is demand, I can revise my decision and integrate this feature. But it will forever remain an advanced interface for experts, alongside the current simple and easy to use interface.

[HadrienG2]

As pointed out by fyl2xp1, the consumer-side expert methods should tell whether the buffer has been swapped since the last time a buffer was read. This allows things like performing in-place post-processing on a value that was received from a producer, and only carrying out the post-processing again when a new value is received.

[HadrienG2]

One argument against giving write access to the consumer is that it will make the synchronization protocol more expensive on relaxed-memory architectures by requiring an AcqRel memory barrier on all writes to the back buffer info (as buffer writes now happen on both sides), where an Acquire-Release pair currently suffices. As there is a compromise between various performance characteristics (in-place writes vs efficient synchronization), the best thing to do might be to make the raw reads and writes an optional feature of the crate.

[HadrienG2]

Okay, I'll do this. There is a prototype of this approach in branch raw-read-write (https://github.com/HadrienG2/triple-buffer/tree/raw-read-write).

[HadrienG2]

Done in v1.1.0