Messages in this thread | | | Date | Sun, 12 Oct 2003 12:59:00 +0100 | From | Jamie Lokier <> | Subject | Re: 2.7 thoughts: common well-architected object model |
| |
asdfd esadd wrote: > There is a connex, fork() might be a bad example, > > it's simple - yes but 20 years have passed as Solaris > is finding: > > pid_t fork(void); vs. > > the next step in the evolution CreateProcess > > [extraordinarily long-winded way of saying the same thing as > if ((pid = fork()) == 0) { set_things(); go(); } ]
Dear asdfd,
How can you possibly think the CreateProcess monstrosity superior to fork in any way? You seem to have picked the canonical example of just what is awful about the Win32 AI and why it's so much work to use.
I cannot think of a single example where CreateProcess is simpler to use - and it's worse than that: it comes with a bunch of assumptions and limitations, exactly the kind of thing that presumably you expect "a component model" to _not_ have.
What do you do when you want to create a process with a property that _isn't_ listed in the arguments to CreateProcess? Yes: you have to set those in the child process, just like with fork().
So what's the point in having some of the properties listed in CreateProcess? Answer: none. Not from an API cleanliness point of view anyway.
> System.Object > System.MarshalByRefObject > System.ComponentModel.Component > System.Diagnostics.Process > [C#] > public class Process : Component > [C++] > public __gc class Process : public Component
This begins to make more sense. You do understand that unix has this class too, but it's called pid_t, not Process?
> * unified well architected core component model > which is extensible from OS services to application > objects
Yeah, but CreateProcess _isn't_ well architected. It's among the worst of excreta in Win32.
> * the object model should be defined from the kernel > layer for process/events/devices etc. up and not > started at the application layer
Unfortunately you just state this, without giving any reasons for it.
If this were implemented in userspace (i.e. the Mono project), can you give a single reason why it needs to be extended into the kernel?
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |