harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Ellison (JIRA)" <j...@apache.org>
Subject [jira] Closed: (HARMONY-665) [classlib][nio]Charset.encode()/decode() should be more safer for multi thread using
Date Thu, 03 Jan 2008 12:49:35 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tim Ellison closed HARMONY-665.
-------------------------------


> [classlib][nio]Charset.encode()/decode() should be more safer for multi thread using
> ------------------------------------------------------------------------------------
>
>                 Key: HARMONY-665
>                 URL: https://issues.apache.org/jira/browse/HARMONY-665
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>            Reporter: Paulex Yang
>            Assignee: Tim Ellison
>         Attachments: Harmony-665-2.diff, Harmony-665.diff
>
>
> As discussion on the mailing list, current Harmony codes may throw exception for the
scenario below:
>          for (int i = 0; i < THREAD_NUM; i++) {
>               thread[i] = new Thread() {
>                   public void run() {
>                      sink.write(ByteBuffer.wrap("bytes"
>                                         .getBytes(ISO8859_1)));
>                     }
>         }
> String.getBytes() actually invokes Charset.encode(), while spec requires Charset.encode()
to be thread-safe. Current Harmony implementation of Charset.encode() holds lock on this Charset
instance, but doesn't synchronize on the system wide cached CharsetEncoder, so it is not safe
for multi Charset instances in multi threads to encode() concurrently. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message