-
Notifications
You must be signed in to change notification settings - Fork 33
Description
Finally, I think we have now conclusively performatively demonstrated that the handling of resources is way too complicated here, given that we are making mistakes basically all the time (see at least this PR, #1640, #1564, #1516), with the caveat that some of them only affect use cases with long-lived registries such as
db-analyser.Therefore, maybe we should try to look for a better/easier-to-use abstraction here; also see what I wrote in #1640 (review):
Not in scope for this PR, but the story around safely and correctly releasing resources for forkers is quite complicated (even more so with this PR), with some parts being handled by a
ResourceRegistryand some parts by a specialStrictTVar m (m ()). I wonder whether we could make some general improvements here; maybe the concept of a temporary registry a larunWithTempRegistrycould be used to streamline this?Another (compatible) idea would be that opening
Forkeralways allocates aResourceRegistry(instead of taking it as an input) to prevent using a single long-lived registry for many forkers.
The way we handle resources with foeResourcesToRelease is very complicated and error-prone. We have to simplify it.