commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Pugh <willp...@sourcelabs.com>
Subject Re: codec - thread safe
Date Tue, 09 Oct 2007 17:04:11 GMT
sebb wrote:
> On 09/10/2007, Qingtian Wang <qingtian.wang@gmail.com> wrote:
>   
>> On 10/8/07, sebb <sebbaz@gmail.com> wrote:
>>     
>>> Which methods do you actually need?
>>>
>>> If you only need BCodec, then that (and Base64 which it calls) look to
>>> be thread-safe, so you only need to instantiate it once for each
>>> different charset.
>>>       
>> Yes, I sort of figured that out for myself already when I first
>> started the conversation with Henri. Now thanks for your help, I got
>> another pair of eyes confirming this. So I am good in my case.
>>
>> But all the discussion has been more about the "in general" case. I
>> just feel that,
>>
>> 1. Codec as a commons library, it should not be this hard to find out
>> about information like this. It should be either this or that, "find
>> out for yourself" is no good situation. As someone else pointed out
>> earlier, we could use a better documentation.
>>     
>
> Agreed. It should be stated clearly whether or not the code is thread-safe.
>   
I attached a patch to this bug.

My solution here was to add static methods called
    createThreadSafeCodec

on all the classes that are thread safe.  For a few, this simply returns 
an instance of the object.  For others, it returns an instance of the 
object that overrides the dangerous set* methods.  That way, if anyone 
tried to use it in an unsafe manner, they will deterministically get an 
error.

My patch also adds a blurb in package.html basically saying this.
>   
>> 2. It'd be nice for the biz method implementations to be thread safe
>> (Ideally in a high performance manner as a value add-on of using a
>> commons brand library such that user doesn't have to be too creative
>> as some of the suggestions given in this discussion to achieve
>> performance). Most of them may already be thread safe. And as it seems
>> agreed by all that it's not hard to make them that way if not.
>>     
>
> For a library such as codec, I agree that it should be thread-safe by
> design. Where this is not possible, the unsafe classes should be
> clearly identified.
>
> I don't think it makes sense to separate methods into "biz" and the rest.
>   
I agree.
> ---------------------------------------------------------------------
> 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