handle gc

Feb 13, 2012 at 10:48 PM

Keith,

  1. I am exploring the lifecycle features of the handle<> class.
  2. I started by playing with test project under the xll project. In test/Source Files/handles.cpp there is a TEST.FOO UDF export. So I started test in debug mode from visual studio, and entered Cell[A, 1] = TEST.FOO("foo"), and then Cell[A,2] = TEST.FOO("boo") in Excel worksheet. Then I proceeded to test what happens when I clear out the contents of the cells. My expectation was that after I clear out the contents of cells containing the TEST.FOO calls, the handles should be removed from the internal cache of handles?
  3. I also set a breakpoint in handle::insert to check on what is contained in the handle_set. I was surprised to find that on every recalc (triggered from excel via F9) VS would stop at the breakpoint in handle::insert and a new pointer structure was inserted in the hashset.
  4. Shouldn't the object handles get removed from the set of handles in the handle<> class, if excel is no longer hanging on to the "foo" object that was inited in the cell?
Coordinator
Feb 14, 2012 at 3:25 AM

I'm seeing the same thing and it is a bug. I recently redid the handle code to use the new std::unique_ptr from the C++2011 standard.

It lets you specify the destructor to be used when allocating an object. The default destructor seems to not be getting called.

One thing my handle code can't handle :-) is when a handle is deleted. You can move it. You can change the arguments to it and the old handle (used to) get deleted. But I haven't figured out a clean way to deal wiith a cell with a handle getting deleted.

Feb 14, 2012 at 4:39 AM
Edited Feb 14, 2012 at 9:53 PM

1. Shouldn't excel also call xllautofree function? I am thinking that for the addin to know when it's time to release a handle, excel would have to tell it when it is no longer holding a reference to the handle (in the form of the string handle). So I also put a breakpoint in xllAutoFree function but did not see excel invoking it (after clearing out cell contents in the xl worksheet).

2. So I was thinking that if a string is returned to represent the object handle, shouldn't it be marked (ie the OPER object returned to Excel) with xlbitDLLFree flag? I could not find a place in the nxll codebase where this bit is getting set for the handles returned back to excel. So that leads me to the question: conceptually what are steps in managing the handle lifecycle?

3. In the Handle wiki page you give a good overview of how to mechanically setup a handle object, but dont really talk about the lifecycle management. I think it would be great if you could a section, if possible - would be much appreciated.

Coordinator
Feb 14, 2012 at 10:45 PM

Fixed. It was a one character change in the handle::find code. I also removed a redundant std::move in handle::insert.

As for xlAutoFree, that gets called when you return an LPOPER or LPXLOPER with xlbitDllFree set. It is independent of handles. Use xll::Auto<Free> to register the function to be called from xlAutoFree.

I've updated the wiki page on handles to discuss handle lifecycles.

Thanks for your input fractal76!

Feb 14, 2012 at 11:02 PM

Great! Thank you!