Re: new module for temporary files in temporary directories

[Paul Eggert]

Bruno Haible <address@hidden> writes:

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

Yes, that's expected.

> 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) ?

Yes, I'm afraid it is.  People are sorting larger files these days,
and GNU sort doesn't always pick good sizes for temporaries.

>> * 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?

The function names use the verbs "enqueue" and "dequeue", not the noun
"queue".  So we don't need a noun; we need two verbs.  How about
"register" and "unregister"?  The comments say that these functions
register and unregister things, so their names might as well reflect
what they do.

After looking at the code a bit more, I have another comment -- more a
question, really.  Are all those "volatile"s really needed?

The C and POSIX standards are basically useless when it comes to
"volatile", so I was wondering what informal rules of thumb you were
using when programming, when deciding when to use "volatile" and when
not to.

This isn't really a fair question, since I ran across the same problem
with GNU "sort" and came up empty.  I still don't understand
"volatile", to be honest.  The occurrences of "volatile" in GNU sort
are sheer guesswork.  I suspect that none of them are actually needed
in practice.

The C standardization committee attempted to define the semantics of
sequence points and "volatile" in an appendix to draft C99, but after
I asked a lot of questions about it they withdrew the appendix.  (Let
this be a warning to you about trying to answer my question.  :-)

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

I know about the POSIX terminology, but I think it's better to stick
with the GNU terminology, even when writing internal code.  Otherwise
I'll have to remember to switch terminologies when turning my
attention from the code to the documentation or vice versa.  It's not
a huge deal, admittedly; just one more thing to worry about.