[X10-core] X10_SCRATCH_CWD=1

[David C. <dc...@us...>]

I just committed a change to svn that adds the following feature to 
X10Launcher (and native X10 executables)

For example:

$ X10_SCRATCH_CWD=1 X10_NPLACES=4 `which X10Launcher` pwd
/tmp/x10_scratch_1fd54a14
/tmp/x10_scratch_4336f695
/tmp/x10_scratch_5f8b7d57
/tmp/x10_scratch_342957d8

This causes each place to be executed with the current working directory 
set to a unique, empty temporary directory in /tmp (or wherever your 
system usually puts temporary files) with 700 permissions.  The current 
working directory when invoking X10launcher does not influence the 
execution when in this mode.  All I/O outside of this scratch space must 
be performed using absolute paths, e.g. in cmdline options for 
input/output files.

The directory names are chosen using random 8 letter hex strings, (seeded 
using getpid()), and if mkdir fails due to a file already existing with 
this name, then the operation is retried up to 1000 times.  Other failures 
(e.g. disk space, permissions, etc) cause execution to abort.

Note that it is not possible to implement X10_SCRATCH_CWD within the X10 
application because JVMs do not allow one to change the current working 
directory.  It is also very difficult to do it before running X10launcher 
because you may not know on which machines the execution will run, as well 
as it being much harder to avoid race conditions between filesystem 
operations.

The directories are *NOT* cleaned up on exit.  If you use this mode, you 
should clean up your current working directory in your X10 code, on 
program exit (or not, if you wish to inspect its contents after the run 
completes).  It is difficult to make X10launcher clean up the directories 
itself when there is no management process watching the X10 process (e.g. 
with a single place localhost execution).