BUG FIX

There was a bug when using Keep that could lead to bad buffer data being read. This release should fix that.

NewMemoryWriter

NewMemoryWriter allows for preallocation of the internal buffer via bufit.NewBuffer(bufit.NewMemoryWriter(make([]byte, 0, CAPACITY))), this can avoid stuttering since the buffer doesn't need to grow as many times to start.

Go Modules & Keep

Adding go.mod, and introducing the "Keep" function.

Keep allows you to specify a minimal amount of bytes to keep buffered. This can be useful if you need readers that join late to have access to a minimal number of bytes even if all other readers have already read ahead.

v1.1.0

API Updates

• Capped buffer API available for fixing the size of the in-memory buffer [prevent unbounded growth]. This does come with the caveat that a slow reader can slow other readers and block the writer.
• NextReaderFromNow() creates a new reader which only sees new writes (NextReader() sees data from the start of the buffer, which usually equates to the position of the most behind reader).
• Exposed Buffer.Len() to get the current size of the in-memory buf
• Exposed NumReaders() so you can check current number of subscribed readers
• Added OnLastReaderClose so you can take an action whenever NumReaders() falls to zero after a Reader close (so it won't trigger when the writer starts off at 0 readers).

Important Note: regarding OnLastReaderClose: you should be careful about races in your code logic (a new reader could join before/while this callback is run, so you may want to lock between NextReader[FromNow]() calls and this call (and check NumReaders()) if you want to guarantee the number of readers during this call is correct and consistent. I make synchronize these calls in a future release, but for now I want to avoid adding more locks.

Bug Fixes

• Write after close is now an error, special thanks @tmm1
• Multiple calls to reader.close() is idempotent now (previously caused buffer state issues)

v1.0.0

Stable Api.