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@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@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
