> thanks. So, the insertion of the signal handler code into the
>user's execution space is fairly clean/efficient but after each signal
>has been handled, the process transitions back through the
>kernel to get the stack unwound? Assuming that transitions into
>and out of the kernel are expensive, that's what I'm trying to
>track.
The main reason for going back into the kernel is so that the signal can be
unblocked. Otherwise application code could just longjmp directly to the
interrupted context (which is available to it on the stack). A system call is
moderately expensive, probably half a microsecond or so on a StrongARM.
>> When we setup the frame on the user stack, we insert some code which
>> includes a SWI to call the "sys_sigreturn" or "sys_rt_sigreturn" code
>> in the kernel.
In practice this isn't quite what happens in a modern system. Putting the
trampoline on the stack would involve an expensive cache synchronisation so
instead glibc supplies it via SA_RESTORER.
p.
PGP signature
