bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tempdir is not removed.


From: Bruno Haible
Subject: Re: Tempdir is not removed.
Date: Sat, 18 Jun 2011 11:28:27 +0200
User-agent: KMail/1.9.9

Hi,

John Darrington wrote:
> The comment in clean-temp.h says that temp files/directories will be 
> "automatically removed when the program exits either normally or through a 
> fatal signal" .
> 
> However, the code in clean-temp.c seems only to deal with the fatal signal 
> case.
> Consequently, in most cases, they don't get removed (observed on GNU/Linux as
> well as w32).  
> 
> Should there not be a call to at_exit in this module?

That wording is ambiguous indeed. The wording "automatically removed when the
program exits" is meant from the perspective of the end user, not from the
perspective of the programmer.

The module does not call atexit() because that does not work well for complex
programs: There is no way to guarantee an order of execution of multiple atexit
hooks.

I'm updating the documentation:


2011-06-18  Bruno Haible  <address@hidden>

        clean-temp: Improve documentation.
        * lib/clean-temp.h: Explain better how to use this module.
        Reported by John Darrington <address@hidden>.

--- lib/clean-temp.h.orig       Sat Jun 18 11:22:23 2011
+++ lib/clean-temp.h    Sat Jun 18 11:22:02 2011
@@ -43,7 +43,12 @@
    are automatically cleaned up (at the latest) when the program exits or
    dies from a fatal signal such as SIGINT, SIGTERM, SIGHUP, but not if it
    dies from a fatal signal such as SIGQUIT, SIGKILL, or SIGABRT, SIGSEGV,
-   SIGBUS, SIGILL, SIGFPE.  */
+   SIGBUS, SIGILL, SIGFPE.
+
+   For the cleanup in the normal case, programs that use this module need to
+   call 'cleanup_temp_dir' for each successful return of 'create_temp_dir'.
+   The cleanup in the case of a fatal signal such as SIGINT, SIGTERM, SIGHUP,
+   is done entirely automatically by the functions of this module.  */
 
 struct temp_dir
 {

-- 
In memoriam Mona Mahmudnizhad <http://en.wikipedia.org/wiki/Mona_Mahmudnizhad>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]