Re: new module for temporary files in temporary directories

[Bruno Haible]

Paul Eggert wrote:
> Some problems I noticed:
> 
> * The GNU coding standards say that one shouldn't use "path" to
>   describe a file name; "path" should be used for things like PATH
>   instead, which are lists of file names.  Several of the comments and
>   names of functions etc should be changed accordingly.

The GNU coding standards say so when talking about documentation. Here
we are talking about _code_ (i.e. something that is invisible to the user)
that is meant to be executed on POSIX platforms, and POSIX has clear
definitions of the term "pathname" and "filename" (see also under
"pathname component").
  
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_266

> * When 'sort' removes a temporary file in ordinary computation
>   (outside a signal handler), it wants to know if 'unlink' failed so
>   that it can issue a diagnostic (e.g., an I/O error occurred).  The
>   proposed API doesn't seem to allow for this.  Similarly for 'rmdir'.

OK, I can add a verbosity flag, that has the effect of signalling when
an 'unlink' or 'rmdir' operation fails with an error other than ENOENT.
(Since the cleanup handler is registered before the file or subdir
is created, it can happen that the cleanup handler is invoked at a
moment when the file does not yet exist. This is normal.)

> * 'sort' creates and remove temporary files in a certain order,
>   and its asymptotic performance relies on the internal data structures
>   (linked lists) accommodating this order.  I suppose I'll have to
>   review the proposed code to see whether it has similar asymptotic
>   behavior.  The basic problem here occurs when one has many, many
>   temporary files.

The module is, so far, not optimized for asymptotic performance.
How many temporary files does 'sort' use? Is more than 10000 temp files
realistic (each of size > 10 MB, giving a total of 100 GB) ?

> * Why do the functions have 'queue' in their names?  Files don't
>   have to be removed in a FIFO order.

It's a pool of tasks registered for future execution. An unordered queue.
Do you know a good name for that?

Bruno