Skip to content
  • Greg Clayton's avatar
    Switching back to using std::tr1::shared_ptr. We originally switched away · e1cd1be6
    Greg Clayton authored
    due to RTTI worries since llvm and clang don't use RTTI, but I was able to 
    switch back with no issues as far as I can tell. Once the RTTI issue wasn't
    an issue, we were looking for a way to properly track weak pointers to objects
    to solve some of the threading issues we have been running into which naturally
    led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared 
    pointer from just a pointer, which is also easily solved using the 
    std::tr1::enable_shared_from_this class. 
    
    The main reason for this move back is so we can start properly having weak
    references to objects. Currently a lldb_private::Thread class has a refrence
    to its parent lldb_private::Process. This doesn't work well when we now hand
    out a SBThread object that contains a shared pointer to a lldb_private::Thread
    as this SBThread can be held onto by external clients and if they end up
    using one of these objects we can easily crash.
    
    So the next task is to start adopting std::tr1::weak_ptr where ever it makes
    sense which we can do with lldb_private::Debugger, lldb_private::Target,
    lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
    many more objects now that they are no longer using intrusive ref counted
    pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
    pointers).
    
    llvm-svn: 149207
    e1cd1be6
Loading