-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remove canDeleteEarly feature of the framework #12932
Comments
A new Issue was created by @Dr15Jones (Chris Jones). @davidlange6, @smuzaffar, @Degano, @davidlt, @Dr15Jones can you please review it and eventually sign/assign? Thanks. Following commands in first line of a comment are recognized
|
assign core |
New categories assigned: core @Dr15Jones,@smuzaffar you have been requested to review this Pull request/Issue and eventually sign? Thanks |
In HI processing (likely also in HL-LHC pileup environment) the total memory used often has a large fraction (about a half, maybe) consumed by transient products. If we could use the canDeleteEarly feature there in a safe way, we could save on some needed resources. |
@Dr15Jones , do we still want to remove this feature? Looks like it is now used in many places outside FW ( https://github.com/cms-sw/cmssw/search?q=canDeleteEarly&type=code ) |
I think this issue can be closed in favor of #16481 . |
closing it in favor of #16481 |
A long time ago we added a feature that let one say an Event data product could be deleted before the end of processing of the Event. No configuration outside of the framework unit tests make use of this feature.
This feature is dangerous since it requires exact knowledge of each module which may use the data product so the product is not deleted before those modules are run. For modules just getting the container directly the
consumes
call would be able to verify this. However, this fails if the container is associated with aRef
like instance. In that case we have no way to find suchRef
s nor know what modules might use them. When run with multiple threads such aRef
could be dereferenced at the exact same time the framework decides to delete the object.The text was updated successfully, but these errors were encountered: