[lkml]   [2009]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: F_SETOWN_TID: F_SETOWN was thread-specific for a while

    On Sun, Aug 9, 2009 at 7:46 AM, Jamie Lokier<> 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

    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
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-08-10 14:25    [W:0.026 / U:4.168 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site