From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: init's children list is long and slows reaping children.
Date: Mon, 09 Apr 2007 19:52:33 UTC
Message-ID: <fa.GXg6Q6Bj7c+YgkN7O7GnEQ1ii9Q@ifi.uio.no>

On Mon, 9 Apr 2007, Kyle Moffett wrote:
>
> Maybe "struct posix_process" is more descriptive?  "struct process_posix"?
> "Ugly POSIX process semantics data" seems simple enough to stick in a struct
> name.  "struct uglyposix_process"?

Guys, you didn't read my message.

It's *not* about "process" stuff.  Anything that tries to call it a
"process" is *by*definition* worse than what it is now. Processes have all
the things that we've cleanly separated out for filesystem, VM, SysV
semaphore state, namespaces etc.

The "struct signal_struct" is the random *leftovers* from all the other
stuff. It's *not* about "processes". Never has been, and never will be.

It's mainly about signal cruft, because that's the nastiest part of POSIX
threads behaviour, and that can't be clearly separated as one clear
structure.

So
 - it really *is* mostly about signal handling and signal sources.
 - it has some random *cruft* in it that isn't about signals, but even
   that is mostly a matter of "it was random cruft in the original task
   structure too, and it DID NOT MERIT a flag of its own"
 - if you wanted to clean things up, you'd actually make things like
   the "rlimit" info structures of their own, and have pointers to them.

So that cruft largely got put into "signal_struct" just because they were
the last thing to be moved out, along with the signal stuff (which was the
big and painful part). NOT because "struct signal_struct" is somehow about
"process state".

So stop blathering about processes. It has *nothing* to do with processes.
It's primarily about signals, but it has "cruft" in it.

So an accurate name is

	struct signal_struct_with_some_cruft_in_it_that_did_not_merit_a_struct_of_its_own

but that's actually fairly unwieldly to type, and so in the name of sanity
and clear source code, it's called

	struct signal_struct

and that's it.

And people who have argued for renaming it don't even seem to understand
what it's *about*, so the arguments for renaming it have been very weak
indeed so far.

IT IS NOT ABOUT "PROCESSES".

To be a "posix process", you have to share *everything*. The signal-struct
isn't even a very important part of that sharing. In fact, it's quite
arguably the *least* important part to share, which is why it was
separated out as a separate thing absolutely *last*, and which is why we
could do without it for quite long, with just some annoyingly subtle
non-POSIX semantics.

Get it? It's the structure that is *least* important for a "process".

So stop blathering about "processes". Anybody who does that, just shows
that they haven't thought it through!

			Linus