On 08/10/2007, Will Pugh <[EMAIL PROTECTED]> wrote: > David J. Biesack wrote: > >> Date: Mon, 8 Oct 2007 17:01:02 +0200 > >> From: =?iso-8859-1?Q?J=F6rg_Schaible?= <[EMAIL PROTECTED]> > >> > >> > >>> The java.util.concurrent backport > >>> http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this > >>> kind of use. > >>> > >> I know this, but I doubt that we wanna start to depend Apache common > >> components on it ;-) > >> > > > > Agreed; I, like you, was merely suggesting to what Commons consumers might > > do to deal with non-threadsafe codecs. > > > > > Might seem like a silly question, but has anyone found anything that > looks like a threading issue in Codec?
Yes - QCodec has a public method that sets an instance variable (see my comments on CODEC-55). > The code is pretty simple. I did a quick look through the code, and it > seemed like everything was pretty thread safe. It looks like you should > be O.K. as long as: > 1) You don't change the parameters to a codec while it's running, > e.g. changing charsets, etc. See above. Having said that, I think it would not be too difficult to fix the classes so that they are thread-safe. Most of the ones I looked at could even be made invariant. So their thread-safety would only depend on any external calls they made; this could presumably be fixed by providing synchronised versions as suggested earlier. > 2) You should not use a MessageDigest returned by DigestUtils by > multiple threads. This should be clear given the API (it's a SUN api) > > It also seems to me that the difference between code that you can trust > as being thread safe, and code you cannot trust as being thread safe has > a lot to do with whether it is tested for thread safety. Seems to me > like another way of helping out here would be to build concurrency tests > for whichever APIs you are interested using on multiple threads. Not > sure where we would put them yet, but seems like the only way to assure > thread-safety (especially if we could get someone to volunteer running > them on a big beefy multi-proc machine :). Indeed. > >> - Jörg > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
