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
{{ message }}
Repository navigation
Use deepcopy inside ConstantColoringAlgorithm if necessary #257
ConstantColoringAlgorithm is peculiar because it builds the coloring result right away, and then returns the same object over and over again. If people use it from several threads it can lead to race conditions, but only for result types that contain scratch memory (aka acyclic coloring or linear system). This is not possible at the moment but we should remain aware of it if we extend ConstantColoringAlgorithm to the symmetric case
deepcopy is basically internals. It's public API, although perhaps that was a mistake, as it is very easy to misuse, and I don't think there's a generically correct way to use it. In any case, see this warning present in the doc string of deepcopy in development versions of Julia:
It is better to avoid this function in favor of custom copy methods or use-case-specific copying functions. deepcopy is slow and can easily copy too many objects, or generate an object that violates invariants, since it does not respect abstraction boundaries.
Activity
nsajko commentedon Sep 10, 2025
deepcopyis basically internals. It's public API, although perhaps that was a mistake, as it is very easy to misuse, and I don't think there's a generically correct way to use it. In any case, see this warning present in the doc string ofdeepcopyin development versions of Julia:Apart from the above warnings, AFAIK the compiler can't optimize
deepcopycalls well, although I may be wrong.TLDR: I suggest not using
deepcopy.amontoison commentedon Nov 1, 2025
@gdalle Can we close this issue now?
gdalle commentedon Nov 1, 2025
Yes this is fixed by #263