By definition, a "reentrant function" is a function that may be invoked even when it has not returned yet from a previous invocation.

So a non-reentrant function is a function that may not be invoked again between a previous invocation and returning from that invocation.

When a function may be invoked from different threads, then it is certain that sometimes it will be invoked by a thread before returning from a previous invocation from a different thread.

Therefore any function that may be invoked from different threads must be reentrant. Otherwise the behavior of the program is unpredictable. Reentrant functions may be required even in single-thread programs, when they may be invoked recursively, or they may be invoked by signal handlers.

An implementation of "malloc" may be reentrant or it may be non-reentrant.

Old "malloc" implementations were usually non-reentrant because they used global variables for managing the heap. Such "malloc" functions could not be used in multi-threaded programs.

Modern "malloc" implementations are reentrant, either by using only thread-local storage or by using shared global variables to which some method for concurrent access is implemented, e.g. with mutual exclusion.

No, this is confused. Reentrancy ("reentrant-safe", or the somewhat related POSIX definition of async-signal-safe) and thread safety are not the same thing.

A reentrant function is thread-safe, but a thread-safe function may or may not be reentrant.

For instance, if a function uses mutual exclusion (say, posix_mutex_lock() and friends) to ensure thread-safety it won't be reentrant, because if the function is invoked via a signal handler it may deadlock. Which is why many common libc functions like malloc and stdio are not required to be async-signal-safe in POSIX, whereas they are required to be thread-safe.

Who has a signal safe malloc?

POSIX does not require malloc to be signal safe.

Therefore I do not think that anyone has bothered to implement a signal-safe malloc, as this is likely to be complicated.

Allocating memory in a signal handler makes no sense in a well designed program, so not being allowed to use malloc and related functions is not a problem.

On Linux, mmap() is your signal-safe malloc.

POSIX doesn't require mmap() to be async-signal safe, but on Linux it de facto is.

Of course, doing every memory allocation at the kernel level is going to be very slow and resource intensive. But if it isn't on a hot code path...

So it sounds like malloc would be an example of a function which is thread safe but not reentrant.

I could be wrong but isnt that because each thread has its own heap?