In the early days of programming, non-reentrancy was not a threat to programmers; functions did not have concurrent access and there were no interrupts. In many older implementations of the C language, functions were expected to work in an environment of single-threaded processes. Now, however, concurrent programming is common practice, and you need to be aware of the pitfalls.
Use reentrant functions for safer signal handling
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Mutual recursion is more common than concurrent programming and as such is the more common reason to require functions to be reentrant.
From what the article says, a function using free or malloc is not reentrant?
It seems the opposite to me, that a function using static variables will not be reentrant.
From what the article says, a function using free or malloc is not reentrant?
If current implementation malloc/free is not reentrant, then function using these isn’t either. This is avoidable by implementing reentrant versions of memory management functions.
It seems the opposite to me, that a function using static variables will not be reentrant.
It is not opposite:) Both cases are not reentrant (although static variables can be used sometimes to detect reentrancy and adjust function behavior).
no. you cannot use printf from within a signal handler. internally printf() is allowed to malloc() and free() memory which may corrupt your heap management if the signal handler interrupted another malloc() or free() call.
you either code audit every function you call from a signal handler (including libc functions) on all OSes you plan on supporting. or you define a global ‘volatile sig_atomic_t flag’ which you set inside the signal handler and handle in your main event loop.
I once worked on a call whereby a very major database vendor had ingored these simple rules, as layed out by many people not least W.R Stevens. The result was that the customers database completely hung. A signal handler had called localtime (I think) which called something which called malloc() and that was the end of the thread’s forward progress….