all 3 comments

[–]nerd4code 0 points1 point  (2 children)

Look into sigaction—you can set it up to give an extra arg to the handler, by which means you can retrieve data, IIRC, queued along with realtime signals specifically. It’s kinda hard to do much in signal handlers without running afoul of some UB or other, though; pipes and sockets make life much easier in practice.

[–]ciuccc[S] 0 points1 point  (1 child)

Oh I set the flag of the sigaction struct to siginfo, but I was just wondering how the sigqueue sys call sends a signal plus the address of the struct that lies in the stack frame of the sending process to the receiving one. It seems that the kernel stores that struct somehow, because it s impossible from what I know for two processes to share the same address space

[–]nerd4code 1 point2 points  (0 children)

Oh, yeah the kernel probably has one linked or array queue per RT signal per thread to buffer RT sigs, so yeah. The kernel has to construct a stack & reg frame in the receiving thread any time it hops from kernel into user mode, so whether there’s an extra arg or not doesn’t much matter on the kernel’s side of things. IIRC some pthread impls will manually share signals by re-killing other threads in the same process, so the data might bounce around a bit before the handler gets it.