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
std::any::TypeId returns different results for the same non-std type in different binaries. Switch to something else for feeding state through nested graphs.
#43
Open
mitchmindtree opened this issue
Jul 25, 2019
· 0 comments
Currently gantz uses the std::any::Any trait for feeding the state of nodes into nested graphs across dynamic library boundaries. The idea was that using Any would allow us to provide a consistent API that would not require being changed at runtime but would still allow for re-compiling nested graphs as they are interacted with by the user.
The Any trait works by associating each type with a unique identifier that can be checked at run-time in order to allow for safely casting between Any trait objects and types. The problem is that this unique identifier is generated via a hashing process occurring at compile-time that seems to be seeded by some information associated with the current compilation process. While compiling the same crate (without any changes) two times in a row results in the same TypeId for each of its types, TypeIds may be different for the same type compiled in a different crate as a separate compilation target. This makes it impossible to rely on Any trait objects to downcast to types from non-std crates and in turn makes the Any approach infeasible for state handling problem mentioned above.
Instead, the solution might have to be to use unsafe, raw pointers for feeding state into the graph. This will cause some frustrating, confusing issues if for some reason the expected state does match the state delivered by the user, but perhaps some kind of type-safe API can be provided on top to work around this.
The text was updated successfully, but these errors were encountered:
Currently gantz uses the
std::any::Any
trait for feeding the state of nodes into nested graphs across dynamic library boundaries. The idea was that usingAny
would allow us to provide a consistent API that would not require being changed at runtime but would still allow for re-compiling nested graphs as they are interacted with by the user.The
Any
trait works by associating each type with a unique identifier that can be checked at run-time in order to allow for safely casting betweenAny
trait objects and types. The problem is that this unique identifier is generated via a hashing process occurring at compile-time that seems to be seeded by some information associated with the current compilation process. While compiling the same crate (without any changes) two times in a row results in the sameTypeId
for each of its types,TypeId
s may be different for the same type compiled in a different crate as a separate compilation target. This makes it impossible to rely onAny
trait objects to downcast to types from non-std crates and in turn makes theAny
approach infeasible for state handling problem mentioned above.Instead, the solution might have to be to use unsafe, raw pointers for feeding state into the graph. This will cause some frustrating, confusing issues if for some reason the expected state does match the state delivered by the user, but perhaps some kind of type-safe API can be provided on top to work around this.
The text was updated successfully, but these errors were encountered: