Just had an idea to help eliminate double-release errors as well as make it easier for consumers of resource pools to deal with out-of-band error cases (inspired by https://github.com/tgriesser/knex/pull/973). Simply put, instead of removing the resource from the pool when .destroy() is called, instead we can flag it for removal and let things take their natural course. When the resource is released as cleanup, say by a disposer (as knex does), it will see that the resource has been flagged for destruction and remove it at that time.
An argument should be supplied to destroy, something like destroy(defer), to maintain existing behavior as well as avoid making more work in work flows where the caller would not need a global cleanup handler and just wants to destroy immediately.
Just had an idea to help eliminate double-release errors as well as make it easier for consumers of resource pools to deal with out-of-band error cases (inspired by https://github.com/tgriesser/knex/pull/973). Simply put, instead of removing the resource from the pool when
.destroy()
is called, instead we can flag it for removal and let things take their natural course. When the resource is released as cleanup, say by a disposer (as knex does), it will see that the resource has been flagged for destruction and remove it at that time.An argument should be supplied to destroy, something like
destroy(defer)
, to maintain existing behavior as well as avoid making more work in work flows where the caller would not need a global cleanup handler and just wants to destroy immediately.Logging this issue as a todo.