commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: codec - thread safe
Date Mon, 08 Oct 2007 16:56:30 GMT
On 08/10/2007, Will Pugh <willpugh@sourcelabs.com> wrote:
> David J. Biesack wrote:
> >> Date: Mon, 8 Oct 2007 17:01:02 +0200
> >> From: =?iso-8859-1?Q?J=F6rg_Schaible?= <Joerg.Schaible@Elsag-Solutions.com>
> >>
> >>
> >>> 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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message