graph-prototype
graph-prototype copied to clipboard
Redesign of InputSpan and OutputSpan
Description:
InputSpan
and OutputSpan
classes maintain internal states (e.g., tagsPublished
) that are unique to each instance and not shared among different instances. Copying these objects without proper state management can lead to incorrect behavior when methods like publishTag()
are called.
For example, in the processBulk
function, when InputSpan
or OutputSpan
objects are passed by value, their internal states are copied. This can result in inconsistent or unintended behavior due to the duplication of state information. While processBulk
illustrates the problem, the underlying issue is broader: we need to avoid scenarios where internal states are copied for each instance.
Questions:
-
Should we move all internal state members to
CircularBuffer::Reader
andCircularBuffer::Writer
?- Centralizing the internal states within the
Reader
andWriter
makes all states shareable between instances.
- Centralizing the internal states within the
-
Should we prevent copying of
InputSpan
andOutputSpan
to enforce proper state management? AND Should we disallow obtaining spans several times without ensuring thatconsume()
orpublish()
methods are called?- By deleting or disabling copy constructors and copy assignment operators, we can ensure that instances cannot be copied. + there are no 2 instances which point to the same span of data, could ensure that state changes occur in a controlled manner.
Note: This issue highlights the need for careful handling of internal states within InputSpan
and OutputSpan
to prevent incorrect behavior due to improper copying or state sharing. Feedback and suggestions on the proposed questions and action items are welcome.