Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of t.p.ellison@gmail.com
 designates 209.85.161.49 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=hS/C9egE/7ZSiLN7F8EZK1twDrop7M0Xd8BsX/kc6ffdoyqkk0XU4cT+qFzOWvyIJF
         MMzhjqXw2NK/Y+sWMO7Z6TqUoQ+kgGU8B4HURZu10UxiwPHaHbp2ZJZ2hcZyMgVxllyP
         65tOX6pSwBqtq3xwNtQwnrCgSOkHANtO/gtxU=
Message-ID: <4C344478.7070200@gmail.com>
Date: Wed, 07 Jul 2010 10:10:16 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: [classlib][luni] creating temporary files (was: Re: svn commit:
 r960424
 -
 /harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/java/io/File.java)
References: <20100705030517.1F57223889E5@eris.apache.org>
 <201007061356.o66Du8Md001843@d06av02.portsmouth.uk.ibm.com>
 <AANLkTinsT2AfVDLXXn8767i9NNj5JhqazxmsBmNJTOp8@mail.gmail.com>
In-Reply-To: <AANLkTinsT2AfVDLXXn8767i9NNj5JhqazxmsBmNJTOp8@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06/Jul/2010 15: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.

I'm confused ... the code I'm looking at in File (before Regis' changes)
do have the create in a loop.

Not showing some checking etc, it says,

  public static File createTempFile(String prefix, String suffix,
          File directory) throws IOException {

      File result;
      do {
          result = genTempFile(prefix, newSuffix, tmpDirFile);
      } while (!result.createNewFile());
      return result;
  }


the genTempFile is having a good guess at creating a unique name, in
pseudo code:

  private static File genTempFile(String prefix, String suffix,
      File directory) {

      if atomic counter is not set, initialize to a random number
      return File (dir, prefix + counter.getAndIncrement() + suffix);
    }


and the "while (!result.createNewFile())" loops while the creation
reports the file exists.

So what was the original problem that needed fixing?  Multiple threads
should have a different value for the 'counter' and multiple VMs are
either separated by the random number initialization, or have to spin on
a test and re-gen a name if they collide.


> 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.

Agreed.  As shown above this code already uses concurrent utilities in
the existing algorithm anyways.

> 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.

We should just assume that we can use concurrent.  VMs will have to
support it as they see fit.

Regards,
Tim