On 03/08, Davide Libenzi wrote: > > On Fri, 9 Mar 2007, Oleg Nesterov wrote: > > > > Logic is, if it's not an RT signal, queue only one, otherwise multiple. > > > The bit on the ->pending mask is clealer only when the queue slot becomes > > > empty. > > > > Yes, I see what the code does, but I don't undestand why. For example, > > SIGCHLD was > > delivered to the process _and_ handled several times, then > > sys_signalfd_dequeue() > > comes and finds only one siginfo. Isn't this strange? > > That's the same logic the kernel folows for non-RT signals.
Yes, specific_send_sig_info/__group_send_sig_info "ignores" the non-RT signal - if we already have a pending one (blocked, or not yet handled) - the only reason is backward compatibility signalfd: - if the same signr was not fetched via sys_signalfd_dequeue() - the reason is ???? Suppose we are doing a simple application which just logs all signals which were sent to this process. Now, we can miss the signal if the logging blocks. Think about sub-threads. We can send the same non-RT signal to T1, T2, T3 via specific_send_sig_info(). All 3 signals will be delivered, but signalfd (which is process wide) will see only the first. > > > The two trasports can rely on different masks. The signalfd_notify() does > > > not even go in signalfd_deliver() if no signalfds are attached to the > > > sighand. > > > > Sorry, I don't understand. The masks are different, yes, but ->sighand is > > the > > same? How this can make any difference for "if no signalfds are attached" ? > > The list_empty() che would not make you fall inside signalfd_deliver(), > hence the fast path really lives up to its name ;) Ugh. Still can't understand, probably I missed something or misread this patch. If we shift signalfd_notify() from specific_send_sig_info/__group_send_sig_info to send_signal(), we have the same "list_empty()" fastpath if no signalfds are attached to the sighand. The difference is that we don't count sig_ignored() signals, which looks right to me. Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/