It certainly does not violate POSIX, whatever gave you that idea?
Furthermore, you're in a new process group every time you say
The session id stays constant (as long as cmd does not disassociate
itself from the controlling terminal with a setsid()), but the shell
will put the cmd process in its own process group for ctty reasons
(so you can stop/start/kill it).
Using process groups for the signals will work just fine. If "cmd"
is a multi threaded app which calls a bunch of clone()s to get a bunch
of threads, all those threads are in the newly created process group.
: So I'd be happier if we could find some clean
: and lightweight way of adding a new grouping mechanism so we can
: properly support POSIX thread killing semantics *and* not interfere
: with process groups.
With apologies to South Park, this makes me a sad, sad Panda :-)
In other words, I'm a little disappointed in this line of reasoning
and want you to reconsider reconsidering...
You do not have any reason to do this, you just think it would be a
good idea. You haven't proved that is a good idea or even given a
plausible reason why it might be a good idea, yet you are willing to
say we need a new set of interfaces to do what the old interfaces do
just fine. It's that sort of thinking that leads to APIs like Win32 -
that steaming pile of doo doo. Don't go there. Going there makes for
sad Pandas. Strive hard to make new stuff fit in the old models and
create new models only after exhausting every way of fitting in the old.
Think about it. If you could make everything fit into the existing
clone/kill/signal/wait set of intefaces, the only new doc which needs
to be written is the clone(2) man page and the mutex_enter(3) man page.
The rest of the stuff is already there (yeah, yeah, I'm sure I forgot
some other man pages, but the point is code/interface/model reuse, not
You could think of this as a sort of "object oriented" approach to
design. You always try and make new things be new instances of an
existing class. In this case, we have the process class and a set of
"methods" on the class. The thread class is really, really close to
the process class. So why are you in such a hurry to define two
classes? Can't you see the value of all the existing code which
knows about the methods on the process class? All that stuff has to
be retooled to know about _anything_ you add which is a new method or
a new semantic. That's a really really bad idea.
Even if you have some new semantics for which there are no analogs in
the process class, that is no excuse to create a new class. If you must
(I don't see why) then inherit the process class, preserving all of
the methods and semantics and add the oddball ones. At least then you
get the benefit of all the tools which know how to talk to processes,
and only in the oddball cases do you need oddball tools. In the POSIX
model, the same semantics have different interfaces. Call me arrogant
or whatever you like, I think it's stupid and I don't think any of you
should bow down to some committee and be stupid too. Do the right thing.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/