On 05/05/2017 12:56, Robert Elz wrote: > Date: Fri, 5 May 2017 11:49:28 +0100 > From: Roy Marples <r...@marples.name> > Message-ID: <d4678b06-236a-286d-eaf8-19d40971a...@marples.name> > > | In this case, exit() isn't called, the main function returns. > > Same thing, return from main is defined as implicitly calling exit. > > | In the RTEMS case, everything runs in one process and a thread is > | launched for each command, sharing memory thus exit() can never be called. > > It doesn't need to "exit" in that sense, but when that thread completes, > whatever resources it allocated needs to be reclaimed (whether they be > file descriptors, or memory, or whatever else). How that is done is the > implementations business, but it needs to be done. > > If not, you'd have bigger problems with tic if you intended to run it > on such a system - I see its grow_tbuf(), save_term(), write_database() > (and main(), though those calls are less of a problem) fuunctions all call > err() on error. err() is defined not to return. No memory gets > freed, nothing gets closed, other that whatever side-effect of the > program completing (calling exit) is.
FreeBSD has err_set_exit(void (*exitf)(int)) to handle this. I suppose atexit(3) could be used as well. But that's more of a technical nit than suggesting we make tic 100% free stuff, which is not what I'm suggesting. > | So my question stands, is this something we should support via a compile > | time guard or just not bother? > > Leave the __VALGRIND__ guard in, and clean up in that case only, not that > a program like tic should really be too concerned about memory loss, > because exit (or whatever happens to it when it falls off main) really > needs to clean up for it, but just in case someone wants to debug > its memory use (perhaps it might be of use when debugging the hash table > library functions memory uses - to make sure that when the program does > hdestroy*() that everything is freed ... as while tic really doesn't > care, some other long running daemon program might.) > > Or if debugging memory use in tic isn't important, simply delete the > whole code block (turn the #ifdef __VALGRIND__ into #if 0, and then > delete the entire block later.) Debugging memory use is always important. I'll move it to a separate function for clarity, but was hoping a better guard name than __VALGRIND__ could be used. Maybe __DEBUG_MEMORY__ or __FREE_RESOURCES__? Roy
