Hold on. What about a process that fork()s, the parent process does
something and the child (with pid=cpid) then does setpgid (0, cpid);
and then creates threads.
Now we want to send a signal to the group which has the parent *and*
child processes. But we can't, right?
> : 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...
Maybe I should have written my proviso in shiny red letters. I said
"if we could find some clean and lightweight way"... I'm not saying
that there *is* a clean and lightweight way.
> 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.
OK. Is there a way of supporting the example I quoted above with
process groups? How would you do it?
> 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.
Larry, I hate to disappoint you, but you're agreeing with me :-)
This is why I said that if we can't cleanly support POSIX semantics,
we should try and get POSIX changed. But first we should let people
coding patches show whether or not they can provide a clean
implementation of POSIX semantics.
Regards,
Richard....
-
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.tux.org/lkml/