> BTW: I find it a bit of a pain when I create a dozen threads per
> application that I get a very long process table: it makes it hard to
> see other stuff amongst the threaded processes. Is there any
> possibility that in the future Linux will in some way hide these extra
>
> processes? Despite its shortcomings, the Solaris model of hidden LWPs
> (yes, I know you can see them if you really want) within a single
> processes does have some benefits.
> Perhaps another flag to clone() such as CLONE_NO_PROC_ENTRY?
>
> Regards,
>
> Richard....
Hello,
About a year ago a least was a a discussion about fixing up the
CLONE_PID flag so that thread id's would be encoded in the upper bits of
the pid. One could have ps list only the proc info for the initial
thread (or other thread if the initial has exited), and be able to see
what initial process all the threads are associated with.
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)
* 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.
Peeter