Repository stuff is not thread safe in BCEL, it is used to read classes, It
is one of the most common problems for
I am sure it is no synchronization problems for enhancer, but we can
synchronize "define" in CodeGenerator and make this method final, it will
solve all synchronizations problems for all backends.
> On Sat, Jun 07, 2003 at 10:56:29AM -0700, Chris Nokleberg wrote:
> > On Sat, Jun 07, 2003 at 04:06:04PM +0300, Neeme Praks wrote:
> > > However, I think CGLIB usage of BCEL should also be synchronized... or
> > > is it already?
> > No, we only synchronize in the public classes (e.g. Enhancer), and that
> > is just to manage the cache of generated classes.
> > I don't want to just add synchronization to the backend arbitrarily. Do
> > you have any information on what in BCEL is not threadsafe?
> I saw the message in bcel-devel about the Utility methods. They
> definitely aren't threadsafe, but I've traced back to where they are
> used and it's only in the toString() methods of a few class. I put in
> some debugging and confirmed that we don't use those methods anywhere in
> CGLIB. I there is another area of BCEL that you believe to be unsafe,
> please let me know.
> FWIW here is my dependency tree from the unsafe fields in Utility:
> field "consumed_chars"
> methodSignatureArgumentTypes(String, boolean)
> methodSignatureToString(String, String, String, boolean,
> methodSignatureToString(String, String, String)
> methodSignatureToString(String, String, String, boolean)
> signatureToString(String, boolean)
> methodSignatureReturnType(String, boolean)
> field "wide"
> codeToString(ByteSequence, ConstantPool, boolean)
> codeToString(ByteSequence, ConstantPool)
> codeToString(byte, ConstantPool, int, int, boolean)
> codeToString(byte, ConstantPool, int, int)
> This SF.net email is sponsored by: Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at http://www.etnus.com.
> cglib-devel mailing list