> On Oct 7, 2014, at 10:15 PM, Matthew Gardiner <[email protected]> wrote:
>
> On Tue, 2014-10-07 at 17:10 -0700, Greg Clayton wrote:
>> It is quite common for shared libraries to have initialize and terminate
>> calls. We have this in LLDB.
>
> Agreed. Lots of libraries have to initialise resource, then release the
> resource upon terminate.
>
> But why have an Initialise method when you _already_ have a Create
> method? Likewise a Terminate method when you _already_ have a Destroy
> method.
>
> Surely when a "thing" is created that is also when it is initialised?
You are assuming there is no global context within the debugger like all
registered plug-ins, lists, settings, global module list... These all work
without requiring a debugger object. We could switch things so that all state
is contained in the lldb_private::Debugger object, but then all places making
static function calls would now need to have a debugger object. So think of
SBDebugger::Initialize() more of a LLDB::Initialize() and
SBDebugger::Terminate() as LLDB::Terminate(). We placed it into the SBDebugger
class just for convenience since this is the most senior object in the
hierarchy, but I can see how this is confusing.
>
>>
>> I would rather not have to look through all API calls that might require
>> LLDB to be initialized and have to possibly manually call
>> SBDebugger::Initialize() in there. The initialization does quite a bit and
>> the assertion quickly should tell you that you must call
>> SBDebugger::Initialize() first. If it isn't clear from the assertion, we can
>> change the assertion to be more descriptive. But again, many other classes
>> in the lldb::SB* API have functions that might be able to be used without
>> having to start with a debugger, so I would rather not have to go through
>> all of the API and add the "init the debugger if not already initialized".
>>
>> This also allows you to use LLDB as a shared library and do:
>>
>> SBDebugger::Initialize()
>> // Do something that takes up a bunch of memory
>> SBDebugger::Terminate()
>>
>
> Agreed. But surely in between the invocations of Initialise and
> Terminate, you have in some sense "created" an instance of an
> SBDebugger?
No that isn't required. There are other API calls you might be able to use (not
many). Repeating what I stated above: SBDebugger::Initialize()/Terminate() are
more really like LLDB::Initialize() and LLDB::Terminate(), so these calls are
really things that populate all shared library globals.
>
>
>> So I vote to leave things as is.
>>
>
> To avoid rocking the boat, I reluctantly concede.
Since we already have this in the SBDebugger public API I would rather not
change it, but it would be probably clearer if we had:
namespace lldb {
void Initialize(); // Must be called prior to calling any other lldb::SB
API calls
void Terminate(); // No lldb::SB API calls should be called after calling
this and before calling lldb::Initialize() again
}
Does that help explain what SBDebugger::Initialize() and
SBDebugger::Terminate() actually are despite the wrong class scoping?
Greg
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
