> On Oct 7, 2014, at 10:15 PM, Matthew Gardiner <m...@csr.com> 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
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to