allocated pthread_mutex_t* use the "malloc()", when the program aborted or exit, it need to free it? if not free it, it will have problems? just i know, the system will reclaim memory when your process terminates. the pthread_mutex_t may have bad effect?
just like the question:
My program (a text-mode web browser) is dynamically allocating memory.
I do free unneeded blocks during runtime, of course. And I do free everything before normal termination - so that memory leak checkers won't give me false positives (and to be flexible should major refactorings ever become needed).
Now, what I do not do is freeing memory before abnormal termination. (Currently, my program terminates on signals and after failed mallocs/reallocs.)
My question is: Do you consider this bad style? Should I free on abnormal termination?
My take on all this 'free everything on normal termination' mantra, (or even abnormal termination), is that, usually, the downside outweighs the upside:
1) The OS has alreday been designed, tested and soak-tested by billions of users. It can easily free all the left-over allocated memory after stopping every thread in any state on any core. Can you do this with your user-code - no.
2) You have to add code to do it. Every time you add code, you potentially add more bugs. Attempting to free all allocated memory in a busy complex, multithreaded system is a nightmare, unless you are an OS. The memory is all over the place, in thread vars, queues etc and may, or may not, being currently accessed by one or more threads. Ownership is uncertain and continually changing. Wot you gonna do?
3) You have to continually test and extend your shutdown system to ensure that all the memory is freed after changes/enhancements/upgrades.
4) Continually checking 'terminate' flags etc. in threads, just so that the threads can free some memory on shutdown, is extra overhead.
5) Many libraries do not free all memory when closed anyway. If the library is opaque/translucent, you may not be able to do anything about it.
6) If a thread throws a serious exception, the memory may be in such a state that attempting to free it from user code will result in yet more exceptions in other threads.
7) Risk/reward - Nice, clean Valgrind output vs. calls/emails from customers 'Hey, your app sometimes will not shut down and we have to call an admin to kill-9/TaskManager it'.
8) Filter and count all the threads on SO re. 'Cannot stop my thread to shut down my app'.
With some apps, it is unavoidable that some threads may have to be terminated in a structured manner on normal shutdown, eg. to commit and close DB connections, flush and close files. Freeing memory does not fall into that category, even for normal shutdown.
If your app is really in serious trouble, you should not try to 'clean up' memory - your app is already dirty, needs scrapping and replacing with a new instance.