[lldb-dev] SBListener not using a shared_ptr internally?

[Jim Ingham via lldb-dev]

What version of the lldb sources are you working with?  I changed the SBListener over to using only the ListenerSP internally
in r262863.

Jim

> On Mar 25, 2016, at 1:03 PM, Paul Peet via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Hey,
> 
> I am currently working on lldb bindings for javascript (v8) but it
> seems that the API is giving me some troubles.
> 
> What I am doing is to basically wrap SB* objects into V8 objects, and
> since SB objects contain a shared_ptr into an internal class I think I
> can simply copy construct them.
> 
> To return a wrapped SB object by some Javascript function, I am simply
> copy constructing the SB object into the wrapper object which is
> dynamically allocated and when the Javascript object is garbage
> collected it will also destroy the SBObject (And also the shared_ptr,
> So it should be save I guess?).
> 
> Okay, so far so good but I detected some inconsistency when trying to
> wrap SBListener. The deal was to make SBListener::WaitForEvent
> non-blocking, to do that I am creating a new thread which calls
> WaitForEvents, when it returns and the event is valid, the callbacks
> given from the Javascript code is called.
> 
> There is a catch when doing this. I have to track the threads which
> belong to a specific SBListener. But there is not actually easy way to
> do this because SB objects are just simply shared_ptr. I noticed the
> GetSP function which returns the shared_ptr of an SBListener, this
> would be a way to solve this issue as I could use a map which maps the
> internal SBListener pointer to a Class object which manages the thread
> and stuff (SBListenerWorker).
> 
> // etc. mutex, ...
> static std::unordered_map<void*, SBListenerWorker*> ListenerWorkers;
> 
> GetSP is protected so I had to create a new derived class:
> 
> class SBListener_Internal : public lldb::SBListener {
> public:
>  SBListener_Internal() = default;
>  SBListener_Internal(const lldb::SBListener& listener)
>      : lldb::SBListener{listener} {
>  }
>  ~SBListener_Internal() = default;
> 
>  void* GetInternalPtr() {
>    return reinterpret_cast<void*>(GetSP().get());
>  }
> };
> 
> I had some worried about if the SBListener object could be destroyed
> at some point and the internal pointer would still be in the
> "ListenerWorkers" map so
> to avoid that I copied the the SBListener object into the class which
> manages the thread and stuff (SBListenerWorker), that means that the
> reference counter should be still > 0 when all other shared_ptrs are
> destroyed.
> 
> Now to the actual problem, it turns out that GetInternalPtr() actually
> returns nullptr and instead uses m_opaque_ptr for calling internal
> functions.
> This means that the SBListener object isn't actually using a
> shared_ptr internally, which brings another question up if it is save
> to use the SBListener across thread? What happens if the SBListener
> gets destroyed.
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev