Messages in this thread | | | Date | Sun, 9 Aug 2009 06:46:01 +0100 | From | Jamie Lokier <> | Subject | F_SETOWN_TID: F_SETOWN was thread-specific for a while |
| |
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.
Starting in kernel 2.5.60, SIGIO signals were thread-specific when F_SETSIG was used to enable queued siginfo.
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
| |