I would be interested at taking a look through this. On Tue, Feb 15, 2011 at 1:33 PM, Daniel Grunwald <[email protected]> wrote: > What I'm currently trying to do is to use my own thread-safe resolver > implementation. > Basically I load assemblies on separate threads (just loading shouldn't > invoke the resolver, correct?). > > But what's also interesting is: > Is it safe to access an AssemblyDefinition (for reading only) from > multiple threads? > > I think this really ought to be safe, at least with ReadingMode.Immediate. > The lazy initialization pattern used by the Cecil properties seems to be > safe - it would be better if the field was marked volatile, but that > doesn't make a difference in this case on the current .NET framework > implementation. > What seems unsafe is the MetadataReader's use of shared state (the > context and reading position); but if I use immediate reading mode, the > MetadataReader shouldn't be used after the initialization, correct? > > Jb please correct me if I'm wrong, I don't want to release a decompiler > GUI with race conditions (and yes, I do a lot of multithreading to keep > the UI responsive). It seems to work fine so far - but then again, it > also seems fine with deferred reading mode, which means I'm just > (un)lucky and didn't hit the race condition so far. > > Daniel > > > On 2/15/2011 13:09, Jb Evain wrote: >> Let me be perfectly clear : maybe. >> >> Seriously, I don't think there are many things easily parallelizable >> in Cecil without adding lots of locking. >> >> On Tuesday, February 15, 2011, Simon Cropp <[email protected]> wrote: >>> JB >>> >>> Do you have an plans to make use of multiple threads when reading and >>> writing assemblies with cecil? >>> >>> -- >>> -- >>> mono-cecil > > >
-- Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer de votre attention -- -- mono-cecil
