Bruno Haible <[EMAIL PROTECTED]> 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.