Shachar Shemesh <[email protected]> writes: > Hi all, > > As we all know, from a signal handler it is only safe to call > functions that are "async signal safe". I have a couple of questions > (three, actually), if anyone happens to know the answer to: > > First, why the name? The list contains functions that are obviously > not async. Does that mean these functions are only safe in > non-blocking mode? (make sense, but you'd expect it to be better > documented) > > The second is why isn't mmap and munmap on this list? These are > functions that are handled entirely by the kernel, and will, therefor, > never block on something that is up to the program that is currently > halted by the signal. Mmap is, in fact, marked as async-signal-safe on > Solaris[1]. And yet, Posix decided not to include it in its list. On a > related note - is mmap async-signal-safe on Linux?
Hi Shachar, I suspect you misinterpret the intent of the standard a bit. The standard specifies that the implementation of the functions on the list must guarantee that they are safe. Other functions may also be safe in particular implementations (mmap on Solaris is an example, apparently), but the standard does not require it. "Safe" in the context means the following: if an "unsafe" function is interrupted by the signal and the handler calls the function, too, the resulting behaviour is undefined. Once again, if I understand it correctly all that POSIX requires is that the functions on the list should be "safe" in this sense. It does not say that other functions are not safe. [Source: "man 7 signal"] Adding a general note: I have been under the impression that safe signal handling normally involved setting some flag in the handler and returning control to the main flow as soon as possible. There one can check the flag and do whatever needs to be done. Note that POSIX is actually a generalization of the ISO C standard that says that only abort(), _Exit(), and signal() are safe to call in handlers. Adding an uncertain note on mmap: I do not know if it is async-signal-safe on Linux. At least one danger is a deadlock: if a function locks something, gets interrupted by a signal, and gets called by a handler, you are in trouble. Apparently on Solaris mmap is guaranteed not to lock anything. On Linux - dunno: is MAP_LOCKED relevant? I'd handle with care... > And, lastly, what is the signal delivery flow in the kernel? What > happens when a signal arrives in the middle of a blocking system call? > Is the signal handler really called before the system call code has > finished? The prospect seems so absurd to me that it defies all logic, > as well as my understanding of the process, but that is the only > explanation I have for why mmap should not be signal handler safe. Isn't it also described in "man 7 signal", in the section called "Interruption of System Calls and Library Functions by Signal Handlers"? [Also in "Interruption of System Calls and Library Functions by Stop Signals" right after that.] I may be misreading your question here. Hope it helps, anyway, -- Oleg Goldshmidt | [email protected] _______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
