Extract optrack fields into WT_CONN_OPTRACK structure

XMLWordPrintableJSON

    • Storage Engines, Storage Engines - Persistence
    • 105.23
    • None
    • None

      Background:

      As part of SPM-3483 (Modularizing WT Connection), WT-11393 moved connection-level locks into a new WT_CONN_LOCKS sub-struct. However, optrack_map_spinlock was pulled into WT_CONN_LOCKS even though it exclusively guards optrack_map_fh and optrack_path, which have no sub-struct of their own. This separates the lock from the data it protects — a readability regression flagged in the WT-11393 PR review.

      Task:

      Extract all four optrack fields from __wt_connection_impl into a new WT_CONN_OPTRACK structure:

      • optrack_map_spinlock (currently in WT_CONN_LOCKS — move out)
      • optrack_path
      • optrack_map_fh
      • optrack_pid

      Access will be via conn->optrack.<field>. Remove optrack_map_spinlock from WT_CONN_LOCKS once it is housed in WT_CONN_OPTRACK.

      Files affected:

      • src/include/connection.h — Define WT_CONN_OPTRACK structure; remove fields from __wt_connection_impl and from WT_CONN_LOCKS
      • src/include/wt_internal.h — Add forward declaration and typedef for WT_CONN_OPTRACK
      • src/conn/conn_handle.c — Update init/destroy for optrack_map_spinlock
      • src/optrack/optrack.c — Update all field access paths
      • Any other files referencing these fields

      Definition of Done:

      • New WT_CONN_OPTRACK structure defined in connection.h containing all four optrack fields
      • optrack_map_spinlock removed from WT_CONN_LOCKS and added to WT_CONN_OPTRACK
      • All three remaining optrack fields removed from __wt_connection_impl and placed in WT_CONN_OPTRACK
      • All references updated to conn->optrack.<field> throughout the codebase
      • Code compiles cleanly with no warnings
      • All existing tests pass
      • Grep confirms no stale references to old field paths (search for field name without variable prefix, not just conn->field)

            Assignee:
            Etienne Petrel
            Reporter:
            Etienne Petrel
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: