harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: svn commit: r960424 - /harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/java/io/File.java
Date Wed, 07 Jul 2010 04:49:00 GMT
On 2010-07-06 22:49, Jesse Wilson wrote:
> On Sun, Jul 4, 2010 at 8:05 PM,<regisxu@apache.org>  wrote:
>
>> File.counter could be accessed by multiple threads, so use AtomicInteger to
>> make
>> sure each thread using different int value to create temp file.
>
>
> Is this a sufficient fix for the problem? The file system may be shared by
> multiple concurrently-executing VMs. Coordinating access to temp files
> within a single VM doesn't prevent other processes from grabbing the same
> file names.
>
> A more robust solution might involve including the VM's process ID in the
> filename. Or perhaps some kind of create-and-test protocol in a loop.
>

At r961242, I used counter value generated first time to identify different VM 
instances, I think that's enough to avoid name conflicts.

>
> On Tue, Jul 6, 2010 at 6:56 AM, Mark Hindess<mark.hindess@googlemail.com>wrote:
>
>> This breaks the build for the IBM VME (from developerWorks).  Since they
>> don't have a sun.misc.Unsafe, so the AtomicInteger can't be resolved.
>>
>
> If VME is to stay modern, they're going to need to support
> java.util.concurrent. I don't think Harmony should provide a
> lowest-common-denominator class library; supporting systems that don't have
> j.u.c is an unnecessary handicap.
>
> Particularly since they can implement AtomicInteger using less efficient
> concurrency primitives. There's even a full
> backport<http://backport-jsr166.sourceforge.net/>that could close some
> gaps if the standard java.util.concurrent isn't
> feasible for their VM.
>


-- 
Best Regards,
Regis.

Mime
View raw message