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
Non-deterministic behavior when accessing IonValue instances from multiple threads is usually caused by violating the library's multi-threaded contract, which requires calling makeReadOnly in a single thread before initiating concurrent access. However, the symptoms can be hard to distinguish from those of legitimate bugs in ion-java. In order to assist in root-causing non-deterministic behavior, we could consider adding a "debug mode" IonValue implementation that can be temporarily enabled. This could record the threads that access each instance and determine whether concurrent access occurs before makeReadOnly has been invoked on the instance.
The text was updated successfully, but these errors were encountered:
Crazy idea but If we could introduce readonly/mutable types internally, then we could have a com.amaon.ion...not.thread.safe...IonStructLite or the like - make things more obvious as issues are encountered.
Non-deterministic behavior when accessing IonValue instances from multiple threads is usually caused by violating the library's multi-threaded contract, which requires calling
makeReadOnly
in a single thread before initiating concurrent access. However, the symptoms can be hard to distinguish from those of legitimate bugs in ion-java. In order to assist in root-causing non-deterministic behavior, we could consider adding a "debug mode" IonValue implementation that can be temporarily enabled. This could record the threads that access each instance and determine whether concurrent access occurs beforemakeReadOnly
has been invoked on the instance.The text was updated successfully, but these errors were encountered: