Merge lp:~spud/spud/get-set-manager into lp:spud
Status: | Merged |
---|---|
Merged at revision: | 437 |
Proposed branch: | lp:~spud/spud/get-set-manager |
Merge into: | lp:spud |
Diff against target: |
309 lines (+79/-48) 6 files modified
diamond/diamond/interface.py (+29/-41) diamond/diamond/tree.py (+11/-6) include/spud (+12/-0) include/spud.h (+2/-0) src/spud.cpp (+16/-1) src/spud_interfaces.cpp (+9/-0) |
To merge this branch: | bzr merge lp:~spud/spud/get-set-manager |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Stephan Kramer | Approve | ||
Review via email:
|
Description of the change
Changes to support accessing spud data inside python diagnostic fields in Fluidity.
This commit adds two new semi-public functions. I don't want to make these fully public (i.e. documented in the manual etc.) because they are a bit of a hack.
The two functions are spud_get_manager and spud_set_manager. These get and set the core internal data structure of libspud, the manager.options of the OptionManager class.
Why is this necessary? Here's what happens chronologically when we have python code that imports libspud:
* Before the fluidity main, the spud constructor is called on the OptionManager object. It allocates options.manager.
* Fluidity calls load_options and that populates the options.manager.
* We use it happily.
* When we import libspud, it calls the spud constructor *on the same OptionManager object*. It allocates options.manager AGAIN, losing the pointer to where we had our data stored.
* That options.manager has no data, and fluidity soon dies because of a want of options.
* At exit, the destructor gets called TWICE on the same fecking OptionManager.
Now, we modify this sequence of events to:
* Before the fluidity main, the spud constructor is called on the OptionManager object. It allocates options.manager.
* Fluidity calls load_options and that populates the options.manager.
* We use it happily.
* Before we load the Python interpreter, we take a pointer to the current good options.manager via spud_get_manager. We store that pointer in a capsule as fluidity_
* When we import libspud, it calls the spud constructor *on the same OptionManager object*. It allocates options.manager AGAIN.
* In the libspud python binding constructor, we fetch the old pointer to the good options manager from the capsule, and set it using spud_set_manager.
* Now we can happily access options from Python, and we haven't lost them from Fortran either.
* At exit, the destructor is called twice, but Patrick has been clever and added a "deallocated" flag so that we only deallocate things once.
Once this is accepted, I will propose the libspud C python bindings for addition, to replace/compliment the ctypes python binding. Once that's done, I will propose the merging of the editions on the fluidity side.
If I understand the story above correctly, and I'm sure that I don't :), "import libspud" will still create a new options manager, except that we use this work around in the libspud python binding to swap it out with the manager we actually want to use. What will then happen with the new manager we're not using? Does it ever get deallocated? Will we not end up with a new unused options manager for every "import spud" that gets evaluated?