[lkml]   [1998]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: A fifo and signal bug
    In list.linux-kernel you write:
    > I tried your patch. It means I cannot no longer interrupt any blocked
    > system calls with SIGTSTP. I don't think it is correct. We need to
    > find a way to keep track who is interrupted in fifo_open and what is
    > is doing.

    I think not being able to suspend a "cat > test.fifo" demonstrates I
    did miss something major -- I expected so.

    However, this does present a dilemma. The POSIX test program expects the
    child to remain as a reader of the fifo, even though it has been stopped.
    To me, this means that the system call must be restarted. On the other
    hand, if I hit ^Z, you want the system call to be suspended.

    One possibility is that POSIX specifies that system calls are restarted
    if the process is killed with SIGSTOP, but not SIGTSTP. If so, then you
    could add a "signr!=SIGSTOP" clause to the previous test I proposed.
    This allows the test to pass, and the process to be suspended using
    ^Z/SIGTSTP. However, my change doesn't feel right, because it appears
    that the stopped process isn't actually stopped.

    I think the specified behaviour that the test program is trying to test
    needs to be explained, so we can work out exactly in which way the test
    is failing (on the machines other than Linus'!). One aspect of the
    test that may be relevant is that the POSIX suite calls setpgid(0,0) --
    is that significant?

    `O O' | Home:
    // ^ \\ | Work:

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:45    [W:0.020 / U:9.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site