At first I thought this was for interprocess communication. But it's not. It doesn't even have the locking for multithread use. This is a micro-optimization for a single-thread, single process program.
The advantage gained with all this memory mapping is that you get to avoid an extra copy coming out of the buffer, because the "poll" function returns a pointer into the buffer, not the data itself. Avoiding that copy creates a potential race condition. When "poll" is called, and returns a pointer into the buffer, it advances "head", indicating the data has been consumed. That space is now both available for writing and being used by the caller as if immutable. The code that calls "poll" must be done with the data before anyone calls "offer". You've now created an undocumented constraint on the callers to "poll" and "offer". If someone doesn't know that constraint and modifies the code, it will randomly break.
Is this micro-optimization really worth it? Modern CPUs are good at copying recently touched data.
This strikes me as being interesting primarily for the potential impact it has on interface design. There are applications of (this sort of) virtual memory manipulation beyond circular buffers. Performance is one consideration, but not the only one.
Also, this is a demonstration - of course it lacks synchronization mechanisms for multithreading! Any particular application of the principle would be adapted for the context in which it occurred (and hopefully be justified thereby).
(As an aside, that caveat only applies if you begin with a poll function that performs the copy itself. That implementation isn't the only obvious one, especially given a large buffer - though I suppose there's room for disagreement on that.)
The advantage gained with all this memory mapping is that you get to avoid an extra copy coming out of the buffer, because the "poll" function returns a pointer into the buffer, not the data itself. Avoiding that copy creates a potential race condition. When "poll" is called, and returns a pointer into the buffer, it advances "head", indicating the data has been consumed. That space is now both available for writing and being used by the caller as if immutable. The code that calls "poll" must be done with the data before anyone calls "offer". You've now created an undocumented constraint on the callers to "poll" and "offer". If someone doesn't know that constraint and modifies the code, it will randomly break.
Is this micro-optimization really worth it? Modern CPUs are good at copying recently touched data.