I still thinking about why grips are locked. The PROPER unlocking
may solve the problem. But we need to include grips into the
marking process. Only locked or marked grips should mark their
content. hb_gcItemRef() can be split into hb_grip_mark,
hb_array_mark, hb_hash_mark, etc. grip becoms one of the common GC
blocks.
Of course the unlocked container is necessary for us and we will have
to add function which allocates such container or as I wrote in
previous
message document hb_gcUnlock() behavior for grip blocks - it will
convert
locked container into unlocked one or in other words remove weak
reference.
It's necessary in both versions but it's not enough. We still need
additional mechanism to scan and mark unlocked block which are
logically
bound. It can be done by user mark/sweep function (the 1-st
version) or
known for GC references chains (the 2-nd version).
Probably the second version gives cleaner final API. F.e. in your
example
it will be enough to introduce only one function used to attach to
other
container and it will internally automatically remove weak
reference (unlock)
the container allocated by hb_itemNew()
It's difficult for me to compare 1-st and 2-nd version, since I do
not understand the 2-nd, but I GUESS the 2-nd does not allow to keep
GC blocks without grip container.
For example, if I want to create a new C object/pointer to store a
sorted array, I would not be able to do it in a way similar to
current array implementation and store items in HB_ITEM array. I
will need to store items in PHB_ITEM array and contain grip for each
item.
It is a rear case, and it could be optimized to store array item
instead of array of HB_ITEM.
I thing we must select the best solution to not slow down HVM, to
make implementation cleaner. Backward compatibility is not an issue
here.
I agree. There are several solutions to solve backward
compatibility, but since we haven't released yet, it's
still a good opportunity to slip in something which
breaks either API or binary compatibility.
We can also use HB_LEGACY_LEVEL2 to obsolete old
functions and add new alternative method. Our .dlls
are version numbered in their name, so it's also OK.
There is still not that many hb_parptrGC() enabled
code out there, so it's not yet late to tweak it in
every place where it's used already.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
