RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9? (SIGPIPE?)

[Robert White]

So I have two threads that are doing IO on a file descriptors with the
number 5, I get an unexpected EPIPE on "5", now what?  I kept track.  Who is
it for?

Yea, I know:

1) add the other flag to clone()
2) mask the signal off completely
3) wake everybody who has a 5 in their file descriptor table (except that I
can't see anybody elses' file descriptor table)
4) wake everybody
5) let the owner task notice the problem when it gets back around to using
"5"
5) Just die like a good little program

Since it doesn't do all the things I expect from the common definition of
"thread"; and it isn't documented anywhere I can find online or in the
kernel tree; what is the kernel actually promising me when I use
CLONE_THREAD anyway?  How is it more than (CLONE_VM|CLONE_SIGHAND)?

[I see a bit about exiting as a group and I assume that CPU usage statistics
are aggregated amongst the threads.  Is that it?]

And I'll bet two dollars I won't be the last to ask... 8-)

You've seen my other arguments about expectation and consistency so I'll
stop now, I promise. 8-)

Rob.

-----Original Message-----
From: linux-kernel-owner@xxxxxxxxxxxxxxx
[mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of Linus Torvalds
Sent: Tuesday, October 07, 2003 7:58 PM
To: Robert White
Cc: 'Albert Cahalan'; 'Ulrich Drepper'; 'Mikael Pettersson'; 'Kernel Mailing
List'
Subject: RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9? (SIGPIPE?)


On Tue, 7 Oct 2003, Robert White wrote:
> 
> If all the CLONE_THREAD members of a process (automatically) have the same
> signal handling code/context but not the same list of file descriptors,
what
> happens when a file descriptor posts SIGPIPE or SIGIO (etc.) to a process?

You have to explicitly _ask_ for SIGIO. If you do so, and you don't share
file descriptors, that's _your_ problem.

But it does indeed have perfectly valid semantics - the signal may well
just wake up a thread: and in fact, as most IO is illegal in signal
handler context anyway, it usually has to. 

Clearly, if you have per-thread file descriptors, you have to keep track 
of which thread is doing what. 

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/