simon wrote on Monday, October 08, 2007 8:19 AM: > On Sun, 2007-10-07 at 15:23 -0500, Qingtian Wang wrote: >> Ok, I got the point. >> >> So let's say I wanted to work on this. What's the most effective way >> to do it? >> >> Search the entire code base line by line trying to ID all the thread >> unsafe points by myself? I guess that's very ineffective compared to >> have an issue open, and have the individual developers who write the >> code to address it - They know what needs to be tweaked without >> having to even spend any time since it's their own code. Or at >> least, the dev team as a whole can come up a list of points that >> need to be worked on. I think that'd be much more effective. Any >> established channel where that can happen? > > I would suggest that you just check the classes/methods that you > yourself want to be threadsafe, and make any necessary fixes. > > There's no obligation to fix anything else; if somebody needs > thread-safety improvements in a different part, then *they* can do it.
[snip] Well, I don't think that this solution is really good. Either codec classes are supposed to be thread-safe or not. A solution where some are and other are not is probably not what is expected. Why not simply go with the JDK Collections approach and provide a CodecUtil with static methods for synchronizedEncoder(), synchronizedStringEncoder(), synchronizedBinaryEncoder and the corresponding methods for the decoders? So everyone can decide on its own whether he need synchronization or takes a pool approach in case of concurrency. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
