At the moment it is not really possible to use this for zero copy processing of incoming data, because you don't get to see the bytes that wrapped around until you released everything at the end of the buffer. But releasing it would obviously enable the Producer to overwrite the contents, so that is not an option.
To work around this, there needs to be an alternative to read() that returns both parts if present. Maybe returning a tuple with the second item as an Option would be possible.
I know it's not trivial, because you can't just return two GrantR, because then you could release the second before the first. So another option might be a special kind of GrantR, that handles both parts releases them correctly. This could possibly use two GrantR internally...
I am just thinking out loud here, but I think it would be possible.
Together with GrantR.buf_mut() you could do almost any kind of data processing in place!
At the moment it is not really possible to use this for zero copy processing of incoming data, because you don't get to see the bytes that wrapped around until you released everything at the end of the buffer. But releasing it would obviously enable the
Producer
to overwrite the contents, so that is not an option.To work around this, there needs to be an alternative to
read()
that returns both parts if present. Maybe returning a tuple with the second item as anOption
would be possible.I know it's not trivial, because you can't just return two
GrantR
, because then you could release the second before the first. So another option might be a special kind ofGrantR
, that handles both parts releases them correctly. This could possibly use twoGrantR
internally...I am just thinking out loud here, but I think it would be possible. Together with
GrantR.buf_mut()
you could do almost any kind of data processing in place!