Nikodemus,
I've already packaged the functionality into a separate library: http://netzhansa.com/temporary-file.html - I have some things to clean up and improve before releasing it into Quicklisp.
The random state in that implementation is protected by a lock - The overhead should be negligible, given that the lock is grabbed in the context of a file operation.
Dealing with the umask has no place in this library. "umask" is a system-specific concept, and file security is something that is orthogonal to temporary files. If an application wishes to give its temporary files different permissions than other files that it creates, it should do so explicitly.
And besides, why put temporary files into a shared directory in the first place? The right way to deal with possible issues in this respect is to create an application specific temporary directory that is completely protected before starting the application, and communicating that directory to the application by the way of the TEMP or TMPDIR environment variable. That is how Windows and OSX do it, and it is much better than trying to protect files in a shared /tmp/ directory. As if we did not have a hierarchical file system for a few decades.
That said, I'm not particularly fond of having a separate library for such a simple thing and I'd be glad to see it be merged to some other utility type library that is not restricted to certain styles of system interfaces (i.e. POSIX).
-Hans
On Wed, Apr 25, 2012 at 6:11 AM, Nikodemus Siivola nikodemus@random-state.net wrote:
I'm coming on the side of saying that this has a place in Madeira, (first version of which I'm releasing before the end of May.)
Madeira can deal with the umask and thread-safety of *random-state*, whereas Alexandria has so far resisted unportable or implementation specific code -- and dealing with those two requires that.
Umask could be degreed to simply be the process umask, which would be suboptimal but acceptable, but thread-safety is more serious -- though I suspect that parallel RANDOM calls should at worst produce degraded quality of random numbers, not corruption or errors, but every time someone assumes "this can't cause serious issues" a kitten dies, so...
Cheers,
-- nikodemus