[MLton] MLton.TextIO.mkstemps

[Matthew Fluet]

>> MLton.TextIO.mkstemps doesn't appear to be working well on
>> x86-darwin
> ...
>> Looks to me like both invocations of mlton ended up accessing the
>> same file.
>
> It does look that way.  Because MLton is deterministic, I would expect
> both MLtons to try the same file, but one of them to get there first,
> and the second to reject it.

That was my belief as well.

> Hmmm.  I tested the following program on
> both platforms (using 20051202 on x86-darwin and HEAD on x86-linux).
>
>  val (s, out) = MLton.TextIO.mkstemps {prefix = "/tmp/file", suffix = ""}
>  val () = print (concat ["file is ", s, "\n"])
>  val () = TextIO.output (out, "data\n")
>  val () = TextIO.closeOut out
>
> I observe the correct (and identical) behavior on both platforms.
> Namely, each time the program runs, it creates a new file in /tmp,
> after considering and rejecting each of the already created files
> (observed via strace).  Note that MLton.TextIO.mkstemps is
> deterministic because it uses MLton.Random, which is deterministic
> unless MLton.Random.srand is called.
>
> Do you get correct behavior with this program?

Yes.  I also considered the following variation:

   val (s, out) = MLton.TextIO.mkstemps {prefix = "/tmp/file", suffix = ""}
   val () = print (concat ["file is ", s, "\n"])
   val () = TextIO.closeOut out
   fun loop () = loop ()
   val () = loop ()

Note that File.tempName (/lib/mlton/basic/file.sml) immediately closes
the temporary file after the call to MLton.TextIO.mkstemps.  I wondered if 
the fact that the process that created the file hadn't terminted and the 
file was empty when the other process tries to open it was making a 
difference.  This program (when run in parallel) also works correctly.