lkml.org 
[lkml]   [2009]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectF_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


\
 
 \ /
  Last update: 2009-08-09 07:49    [W:0.199 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site