Jamie, On Sun, Aug 9, 2009 at 7:46 AM, Jamie Lokier<ja...@shareable.org> wrote: > stephane eranian wrote: >> As Peter found out, the man page seems to indicate that if you specify a TID >> instead a PID with F_SETOWN, then the kernel should interpret this as meaning >> this particular thread, but this is not what is implemented right now. > > The behaviour was changed quietly in kernel 2.6.12. > > I wrote that part of the man page, and it was true at the time. SIGIO > signals _were_ thread-specific. >
I knew at some point this worked because with perfmon we managed to get signals delivered to the right thread. But I guess it was just until 2.6.12 ;-< > Starting in kernel 2.5.60, SIGIO signals were thread-specific when > F_SETSIG was used to enable queued siginfo. > Thank you for bringing up F_SETSIG. I use it in some of my test programs. I thought it was related to the shared vs. private queue. But I looked at it again, and in fact it is related to another yet important issue when sampling. You must use F_SETSIG on SIGIO if you want your signal handler to receive the file descriptor in siginfo. This is useful if you want to perform some actions on the descriptor. That is the case in perfmon and this is the case in certain situations with perfcounters as well. Setting SA_SIGINFO provides siginfo, but the si_fd field is NOT set correctly without F_SETSIG. I have verified this with perfcounters, and this is indeed the case. This behavior seems kind of odd to me. I think it may be a "lucky" side effect of the intended behavior of F_SETSIG. It would be good to clarify this point more. > Prompted by this F_SETOWN_TID patch, I checked through old kernel > patches, and found that signals set by F_SIGSIG were changed to > process-wide in 2.6.12: > > @@ -437,7 +438,7 @@ static void send_sigio_to_task(struct ta > else > si.si_band = band_table[reason - POLL_IN]; > si.si_fd = fd; > - if (!send_sig_info(fown->signum, &si, p)) > + if (!send_group_sig_info(fown->signum, &si, p)) > break; > /* fall-through: fall back on the old plain SIGIO signal */ > case 0: > > That's a bit annoying, because it breaks a library which uses queued > I/O signals as an I/O event mechanism when used with multiple threads. > (Fortunatelly epoll is available nowadays; it does I/O events much > better, but sometimes you want SIGIO from epoll's descriptor...) > > So the man page is now incorrect, but if F_SETOWN_TID is added and has > the behaviour which F_SETOWN used to have, then the text can be > shuffled around. > > If anyone is interested, I have a fairly detailed test program which > checks queued "SIGIO" (F_SETSIG) signals due to I/O on a socket, > including SIGURG and SIGIO on overflow, and checks whether each one is > delivered properly and is thread-specific. I found quite a few Glibc > and kernel bugs with it in the past. > > -- Jamie > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
