It's a pity nothing ever went into the kernel. Threads under Linux is
still a bit clunky. Bit like IRIX threads, actually... At least we
don't have to contend with arenas!
> Last year I also made a whole pile of kernel changes to this effect, but
> I, ... ahem, lost them in a careless upgrade. I am in the process of
> starting over, as I now have some time once again. In the plan is
>
> * the basic changes needed to have stuff in the upper pid bits without
> breaking other places in the kernel
> * modifications to proc to show all thread info under the appropriate
> pid directory, and modifications to procps to handle viewing threads in
> ps (and to fix the breaks that changing proc will make)
I'm not sure that you need to change the /proc interface to show
thread information: I see it as a userspace problem as long as you
have some way of knowing a process is grouped (using pid masks and
searching the process table as needed)
> * modifications to the linuxthreads package for testing all this out
> * other things that may be needed -- linuxthreads needs a little bit of
> help in the kernel in the few places and presumably other more general
> clone based threads need the same sort of stuff. For example,
> linuxthreads uses SIGUSR1, SIGUSR2, and it also needs a "manager thread"
> to handle things like stack cleanup at termination.
None of these address the problem of killing child threads. Although
it's all good stuff you mention: nice to see someone thinking about
all this.
What was Linus' view on encoding IDs in the upper pid bits? It's
certainly good for grouping processes together, though it may be more
prone to introducing bugs than a simple CLONE_NO_PROC_ENTRY like I
suggested, by the simple rule that anything more complicated is likely
to have more bugs :-)
Can I suggest that, where possible, improvements to thread support in
Linux is made as a set of separate patches? We've seen before that
Linus rejects omnibus patches if he doesn't like some bits, even if
other bits are OK. Giving them as separate (independent) patches makes
life easier for him (and hence more likely that "good" patches are
applied quickly).
Linus: it would help people who are looking at doing this if we had
some idea of what techniques you are likely to accept, and which you
are likely to reject. With some of these problems there are a few
different ways of approaching them, so an early indication of what's
likely to be OK would be great.
Below are some of the possible patches that could be developed. Which
ones are OK in principle? Note that some of these are competitors.
* new flag to clone() to allow pids to be "grouped" so that part of
the bitrange for pids are shared within a group. Also needs pid
allocation algorithm to change
* new flag to clone() to either hide a process in /proc or reflect
that the flag was set (thinking about this more makes me think that
this scheme can give much the same flexibility as the above with less
work in the kernel and possibly a little more work in userspace procps
tools)
* new signals for LinuxThreads support (no more stealing of SIGUSR1
and SIGUSR2)
* new flag to clone() or new syscall prctl() so that when a processes'
parent dies, it is sent a signal
Regards,
Richard....