[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.060 / U:0.196 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site