Quote:
Originally Posted by
Corona688
So it's nothing to do with the file-handles, and everything to do with memory allocation? That's unfortunate. You couldn't even call sprintf then...
The problem with heap memory allocation is locks - if the thread the signal is delivered to holds a lock on the heap inside a call to malloc() or free(), for example, the thread will deadlock if the signal handler attempts to acquire that lock.
And that problem is more likely to happen than you might think. Way too many programmers overuse malloc/free and new/delete, effectively single-threading multithreaded applications through the heap. It's not uncommon to get a stack trace for a multithreaded application and see, for example, 45 of its 50 threads all waiting for the same mutex that the malloc() implementation uses. In an app like that, any signal handler that indirectly uses the heap is very likely to deadlock. (Offhand, I think that's because OS's tend to deliver signals to threads that are already running if not the very thread that triggered the signal, and in an app like that most of the threads are sleeping waiting for the heap mutex. Also, in apps like that with massive heap use, the most likely signal is a SEGV to a thread doing heap manipulation in malloc() or free() and therefore already holding the heap lock.)
And there are probably other issues with async-signal safety besides locks, but off the top of my head I can't think of any.
FWIW, on Solaris sprintf() and snprintf() are async-signal-safe. Linux man pages don't specify async-signal safety.
