We could. It just happens to have been done in a piecemeal
fashion. Eventually, setting all of the clone() flags will cause
everything that should be "per-process" to be so. That fact that the
per-porcess data will be kept in several structures, rather than one
as you suggest, isn't particularly significant. And who knows, certain
combinations of clone() flags might turn out to be useful.
> Sure, this will break stuff - most of /proc and lots of other things.
> But it would then allow true kernel threads, where signals were sent
> to the threads structures parent, the process, etc.
The problems with implementing threaded signals are the same whatever
way you look at it: How to quickly select a thread to recieve a signal
sent to the process, but also allowing threads to change their signal
masks quickly. Where to put the pointer to whatever data structures
are needed to implement this fast signal delivery is a minor issue.
> It would also require moving stuff for getrusage, etc. into the
> thread context in part, and leaving other parts in the process
> context and on the whole make life rather nasty to start with.
Yup. There are many bits and pieces to be dealt with. I think the
important thing is to (hopefully in 2.3) build up some momentum
towards a fully conformant POSIX threads implementation, and then take
care of the useful bits and pieces outside the scope of POSIX (such as
rusage, process/thread times, and comprehensible ps output).
> Perhaps thread IDs and process IDs need to share the same namespace,
> so where you get details on a process its the aggregate for all
> threads for fields like CPU time?
That seems like the most practical scheme to me, currently.
> But, once this has been done, and big chunks of userland fixed, the
> end result would be more elegant?
-- Dave Wragg- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html