#1 is no big deal, we could just allocate one in a global class somewhere.
#2 actually seems quite desirable, is there any reason you don't want that?
#3 seems like a win for performance since no locks have to be acquired to
manage the collection of threads
On Sun, Apr 30, 2017 at 9:41 PM Scott S
The overall concept is similar; it comes down to implementation details like
1. llvm doesn't have a global pool, it's probably instantiated on demand
2. llvm keeps threads around until the pool is destroyed, rather than
letting the threads exit when they have nothing to do
3. llvm starts up all the
Have we examined llvm::ThreadPool to see if it can work for our needs? And
if not, what kind of changes would be needed to llvm::ThreadPool to make it
suitable?
On Fri, Apr 28, 2017 at 8:04 AM Scott Smith via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hmmm ok, I don't like hard coding pools.
I think it should be fairly easy to keep interoperability with SBError.
SBError just wraps an lldb_private::Error, so as long as we can construct
some implementation of ErrorInfoBase from an SBError, we should be good to
go. As an extreme example, we could keep LLDBError exactly as is and
provide a
>
> /// ...In the future we may wish to switch to a
>
>
> /// registration mechanism where new error types can be registered at
>
>
> /// runtime instead of a hard coded scheme.
I immediately regret my decision to copy-paste from terminal. :/
- Lang.
On Sun, Apr 30, 2017 at 10:39 AM, Lang Ham
Hi Zachary,
I'm new to LLDB so take my opinion with a grain of salt, but this sounds
like a good idea to me. LLDB is likely to encounter more and more LLVM APIs
using llvm::Error in the future, so renaming lldb_private::Error to reduce
confusion seems sensible.
Replacing lldb_private::Error at so
