You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Comgr] Explicitly describe data object mutation restrictions
Since the early days of the project we have effectively left the
behavior when mutating a data object ambiguous once there is a chance
that it has been shared. As the user has no direct way to know when an
action takes an additional reference to an object, it is
implementation-defined as to when mutation will affect objects which
logically belong to other data sets.
Attempt to clarify the situation by restricting mutation to
newly-created data objects which have not been used as input to an
action and have not been part of the output of an action.
I haven't verified that every use of the library in our codebases is
correct with these restrictions, but the current implementation of
AMD_COMGR_ACTION_ADD_PRECOMPILED_HEADERS effectively assumes this
already, and the natural useage pattern we have intended for the library
conforms.
0 commit comments