enable_shared_from_this objects are sometimes created and owned via unique_ptr

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Won't Fix
    • Priority: Minor - P4
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Server Programmability
    • Programmability 2024-09-02
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      There are a number of places where we own TaskExecutors and ThreadPoolTaskExecutors by unique_ptr. One such example is in the replication coordinator. These are dangerous because a TaskExecutor might invoke shared_from_this in its internal implementation, and those calls will fail because nothing has already taken a shared_ptr to the object. TaskExecutor already does this, albeit in just one infrequently called place, but there's plans in SPM-3750 to use extend this pattern to core functionality of ThreadPoolTaskExecutor (i.e., scheduleRemoteCommand variants and scheduleWorkAt).

      In general, we should consider it a bug to ever create or own an object that inherits from enable_shared_from_this in any other fashion than by shared_ptr because otherwise, we risk the internal implementation calling shared_from_this and failing. I recommend we write a clang tidy rule to prevent such cases and use that as a guide for removing them.

              Assignee:
              Unassigned
              Reporter:
              James Bronsted
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: