This weird test (currently on main) drops a borrowed handle when the current task is different from the task that initially received the borrowed handle. To handle this case correctly, the runtime can't decrement the current task's "number of outstanding borrowed handles" but must instead derive the task from the borrowed handle being dropped.
In more detail: this is the function that receives the borrowed handle and this is the function that drops it. When the latter function returns, it traps with "borrow handles still remain at the end of the call"; I'm guessing because it decremented its own task's counter which underflowed from 0 to non-0.
This weird test (currently on
main) drops a borrowed handle when the current task is different from the task that initially received the borrowed handle. To handle this case correctly, the runtime can't decrement the current task's "number of outstanding borrowed handles" but must instead derive the task from the borrowed handle being dropped.In more detail: this is the function that receives the borrowed handle and this is the function that drops it. When the latter function returns, it traps with "borrow handles still remain at the end of the call"; I'm guessing because it decremented its own task's counter which underflowed from
0to non-0.