Displaying 3 results from an estimated 3 matches for "llvmfooref".
2008 May 12
0
[LLVMdev] Python bindings available.
...is that C++
won't play with your garbage collector at all.
The only other option I can see is to
1. Add an 'owns pointer?' flag to each Python wrapper object.
2. Update that flag dynamically as the value is used, in accordance
with the C++ ownership semantics.
3. Maintain a LLVMFooRef -> Python object table.
So you would reset the 'owns pointer?' flag on m if the user calls
ModuleProvider.new(m).
The table is necessary, else mp = ModuleProvider.new(m2) [using your
example fragment above] would trigger a double free by mp and m1.
Python users are probably not p...
2008 May 12
2
[LLVMdev] Python bindings available.
> Consider the case where a function creates and populates a Module, stuffs it
> in an ExistingModuleProvider for the JIT, then returns the ModuleProvider,
> dropping direct reference to the Module. (ModuleProvider takes ownership of
> the Module.) I presume that your Python object is under the impression it
> owns the Module; when that goes out of scope, its refcount goes to zero
2008 May 12
2
[LLVMdev] Python bindings available.
...h your garbage collector at all.
>
> The only other option I can see is to
>
> 1. Add an 'owns pointer?' flag to each Python wrapper object.
> 2. Update that flag dynamically as the value is used, in accordance
> with the C++ ownership semantics.
> 3. Maintain a LLVMFooRef -> Python object table.
>
> So you would reset the 'owns pointer?' flag on m if the user calls
> ModuleProvider.new(m).
>
> The table is necessary, else mp = ModuleProvider.new(m2) [using your
> example fragment above] would trigger a double free by mp and m1.
>...