This PR has 4 commits, extracted from the future work on child handles. I'd recommend looking at the commits separately because the first commit is bigger, but doesn't change observable behavior (it's just refactoring, based on the better understanding of working on the generalized case), while the other 3 are small and make the following 3 tweaks:
The first change is to only increment lend_count when borrowing an own handle (not when borrowing a borrow). This is almost unobservable (because of synchronous calls) but it is (in the case of parent->child->parent reentrance) and enables a little optimization (as noted in this commit).
The second change fixes a bug in the reentrance check when calling a destructor (the logic was over-trapping when dropping a resource your own component implemented and under-trapping when a resource didn't have a dtor (which should be an encapsulated detail)).
The third change makes resource.drop more like the other two resource.* built-ins by taking a resource type by typeidx. This makes drop a bit simpler and more regular to use for toolchains and I don't expect it is actually useful for optimization, given the branches are needed in any case. It also generalizes better in the future when there are more complicated handle types.
This PR has 4 commits, extracted from the future work on child handles. I'd recommend looking at the commits separately because the first commit is bigger, but doesn't change observable behavior (it's just refactoring, based on the better understanding of working on the generalized case), while the other 3 are small and make the following 3 tweaks:
lend_count
when borrowing anown
handle (not when borrowing aborrow
). This is almost unobservable (because of synchronous calls) but it is (in the case of parent->child->parent reentrance) and enables a little optimization (as noted in this commit).resource.drop
more like the other tworesource.*
built-ins by taking a resource type bytypeidx
. This makesdrop
a bit simpler and more regular to use for toolchains and I don't expect it is actually useful for optimization, given the branches are needed in any case. It also generalizes better in the future when there are more complicated handle types.