Hi, On Tue, Feb 15, 2011 at 9:45 PM, Daniel Grunwald <[email protected]> wrote: > I tested it myself by setting breakpoints in the MetadataReader. > Accessing an AssemblyDefinition from multiple threads is NOT safe, not > even with Immediate reading mode: method bodies are still initialized > lazily.
Yep, I never said nor promised otherwise. > Copy everything I need into my own thread-safe data structures? This is > the approach we use in SharpDevelop, but we don't need any method bodies > there. That would be my choice if you can't make sure that only one thread is accessing an assembly at the time. > From an API point of view, an application that analyses (but doesn't > change) an AssemblyDefinition should be able to treat it as an immutable > object, so it should be able to read from it using any number of threads. As I said since the beginning, only static methods in Cecil's API should be thread safe. > Or should I try to patch Cecil to make it safe for multi-threaded read > access? It seems that I could get away with adding a lock to all the > MetadataReader.ReadXXX methods. That seems painful. We can try to add one lock in ModuleDefinition.Read(Func<>) > Attached is a > simple program that demonstrates how Cecil crashes when accessing a > module from multiple threads (on my quadcore, it crashes 100% of the > time with various types of exceptions). It's quite expected considering the postulate from the start. Jb -- -- mono-cecil
