GalaevAlexey / core-plot

Automatically exported from code.google.com/p/core-plot
0 stars 0 forks source link

CPTAnimation is not thread safe #598

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The current implementation of CPTAnimation is not thread safe and can easily 
brought to crash. This is due to the fact that access to animationOperations 
etc. is not synchronized, but you access these values both with GCD and a timer 
at the same time. So if you add a new animation while update is running you get 
an exception this exception:

*** Collection <__NSArrayM: 0x1012f8450> was mutated while being enumerated.

which then implicitly sets animationOperations to nil which in turn crashes on 
this line:

    id<CPTAnimationDelegate> animationDelegate = animationOperation.delegate;

Beside synchronization between these accesses what's really needed is a better 
handling of animation stop. If I need to destroy a graph because a UI update is 
due I must be able to immediately stop any animation for it as well as any 
access as delegate. This cannot wait until the CPTAnimation timer has come 
around to run update, since my graph might already be gone by then, bombing so 
my application completely.

Original issue reported on code.google.com by mike.lischke on 20 Oct 2013 at 5:26

GoogleCodeExporter commented 8 years ago
I forgot to mention I'm on OSX 10.8 working with the coreplot 2.0 branch.

Original comment by mike.lischke on 20 Oct 2013 at 5:29

GoogleCodeExporter commented 8 years ago

Original comment by eskr...@mac.com on 20 Oct 2013 at 6:23

GoogleCodeExporter commented 8 years ago

Original comment by eskr...@mac.com on 25 Oct 2013 at 6:22

GoogleCodeExporter commented 8 years ago
One solution is to call [[CPTAnimation sharedInstance] 
removeAllAnimationOperations]; when the graph goes away. This is the method 
used by the Plot Gallery example app.

Original comment by eskr...@mac.com on 26 Oct 2013 at 8:24

GoogleCodeExporter commented 8 years ago
This issue was closed by revision 1f17c169e967.

Original comment by eskr...@mac.com on 26 Oct 2013 at 11:46