[Lldb-commits] [PATCH] Expose ThreadCollection in SB API
egranata at apple.com
Fri Sep 5 15:02:12 PDT 2014
> On Sep 5, 2014, at 2:58 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote:
> Will update the patch.
> I don't have a strong opinion whether SBThreadCollection should or shouldn't be read-only. It seems to me its purpose of existence now is to allow SB API to return multiple SBThreads as a single return value. Can't think of any API that would be suitable to have a SBThreadCollection as an input (that the user would construct and populate). If you think we should allow it, I can add it.
It seems like you’re right that we don’t have any need for this now - I was mostly thinking along the lines of users being able to use an SBThreadCollection to store threads internally to their own scripts/programs; but in practice, I suppose Python has lists that can be used, and C++ has std::vector<SBThread> already for this purpose
So, no, I’d say, let’s leave it out for now - and if/when we need it, we can go ahead and make the collection mutable
> On Fri, Sep 5, 2014 at 2:35 PM, Enrico Granata <egranata at apple.com <mailto:egranata at apple.com>> wrote:
> Couple things:
> - why do you need stdio.h in your header file?
> +#include <stdio.h>
> - is there any reason why this constructor is public?
> + SBThreadCollection (const lldb::ThreadCollectionSP &thread_list);
> We are usually trying to keep the constructors that take SPs protected so they are not exposed to API clients; unless you have a compelling reason, I’d do the same here
> For instance, SBData has the following:
> // Mimic shared pointer...
> lldb_private::DataExtractor *
> get() const;
> lldb_private::DataExtractor *
> operator->() const;
> lldb::DataExtractorSP &
> const lldb::DataExtractorSP &
> operator*() const;
> SBData (const lldb::DataExtractorSP &data_sp);
> SetOpaque (const lldb::DataExtractorSP &data_sp);
> You could so something similar in your SBThreadCollection; provide protected accessors, constructor and setter, and only keep the default & copy constructors public
> On a more philosophical note - is SBThreadCollection meant as a “read-only” snapshot of a set of threads as they existed at one time?
> If so, then it’s all fine and dandy
> But it seems that this class lacks any write access; I can’t create a new thread collection and start adding threads to it
> Is this intended in your design, or did you just not feel the need to allow that?
> Mostly curious..
>> On Sep 5, 2014, at 2:20 PM, Kuba Brecka <kuba.brecka at gmail.com <mailto:kuba.brecka at gmail.com>> wrote:
>> Another piece of the puzzle, let's expose the newly abstracted ThreadCollection into SB API, based on http://reviews.llvm.org/D5200 <http://reviews.llvm.org/D5200> and another patch that will actually provide an SBThreadCollection of ASan history threads is coming next.
>> http://reviews.llvm.org/D5218 <http://reviews.llvm.org/D5218>
>> lldb-commits mailing list
>> lldb-commits at cs.uiuc.edu <mailto:lldb-commits at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits>
> - Enrico
> 📩 egranata@.com ☎️ 27683
📩 egranata@.com ☎️ 27683
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-commits