graph-prototype icon indicating copy to clipboard operation
graph-prototype copied to clipboard

Redesign of InputSpan and OutputSpan

Open drslebedev opened this issue 4 months ago • 0 comments

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 and CircularBuffer::Writer?

    • Centralizing the internal states within the Reader and Writer makes all states shareable between instances.
  • Should we prevent copying of InputSpan and OutputSpan to enforce proper state management? AND Should we disallow obtaining spans several times without ensuring that consume() or publish() 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.

drslebedev avatar Oct 08 '24 10:10 drslebedev