kth1068 / ossbuild

Automatically exported from code.google.com/p/ossbuild
Other
0 stars 0 forks source link

Caps.RemoveStructureReferences - InvalidOperationException #109

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Iterating through the Hashtable.Values and removing Hashtable elements. Couses 
InvalidOperationException. 
Enumerator for values is not a clone of the collection, removing elements from 
the collection invalidates the enumerator. Tested on svn revision #971 and .NET 
3.5.

Quick patch attached.

Original issue reported on code.google.com by Slawomir...@gmail.com on 27 Jan 2011 at 9:54

Attachments:

GoogleCodeExporter commented 8 years ago
Please make sure this has been submitted upstream.

Original comment by david.g.hoyt on 27 Jan 2011 at 4:19

GoogleCodeExporter commented 8 years ago
Would this fix the problem instead?

http://cgit.freedesktop.org/gstreamer/gstreamer-sharp/commit/?id=9713ead713201f1
0c0fe4185bc8bb0df4c276cc3

Original comment by david.g.hoyt on 27 Jan 2011 at 6:53

GoogleCodeExporter commented 8 years ago
r972 includes the upstream fixes. Please re-evaluate that the problem has 
resolved itself.

Original comment by david.g.hoyt on 27 Jan 2011 at 7:06

GoogleCodeExporter commented 8 years ago
Yes this fixes the problem. 

But, in my opinion, this can cause additional problems int the future. For 
example when function RemoveStructureReference changes, the same changes must 
by applied to RemoveStructureReferences. This causes problems in code 
maintenance, we have two separate functions that have almost the same code, and 
perform almost the same task.

On the other hand there can by issues with MTA access to this function. For 
example if you have two threads. Thread one calls DoSimplify, and the other one 
calls Merge. First thread enters the iterator and goes to sleep, the second 
thread takes over and runs until the end of RemoveStructureReference. The first 
thread wakes up, and bam exception. 

The matter of MTA access is another history, because the Caps class does not 
support thread synchronization. If we assume that its not thread safe this 
remark in not valid.

Original comment by Slawomir...@gmail.com on 28 Jan 2011 at 6:54

GoogleCodeExporter commented 8 years ago
Those who have the code maintenance problem are the gstreamer-sharp developers 
-- if it's designed poorly, they're the ones who will have to deal with the 
pain.

You'll need to consult the documentation regarding thread safety on the caps 
class. It's been my experience that unless a class is explicitly declared 
multi-thread safe, then you should assume it's not. If there's concern here, 
I'd re-work the class and submit my patch upstream. In their next release, 
it'll make its way back down to us. If it really affects stability, we're 
always willing to consider applying the patch earlier than the next 
gstreamer-sharp release.

Original comment by david.g.hoyt on 28 Jan 2011 at 6:48