The current BufferManager implementation takes in arguments to allocate its own memory, which is fine for the majority of cases. However, there are common implementations (such as reading from a file of a certain format) that would benefit from providing their own single buffer for Pothos to manage.
Each of these BufferManager subclasses allocate their own SharedBuffer and reimplement GenericBufferManager, CircularBufferManager, or some hybrid. The relevant blocks could be refactored to allocate their custom SharedBuffer and pass it to a common implementation. There are other possibilities, but this is the first that comes to mind.
ncorgan
commented
3 years ago
The current BufferManager implementation takes in arguments to allocate its own memory, which is fine for the majority of cases. However, there are common implementations (such as reading from a file of a certain format) that would benefit from providing their own single buffer for Pothos to manage.
Each of these BufferManager subclasses allocate their own SharedBuffer and reimplement GenericBufferManager, CircularBufferManager, or some hybrid. The relevant blocks could be refactored to allocate their custom SharedBuffer and pass it to a common implementation. There are other possibilities, but this is the first that comes to mind.
These blocks end up reimplementing CircularBufferManager's functionality in work(), which isn't correctly scoped.
I'm seeing two additions that could come out of this: