lkml.org 
[lkml]   [2003]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:49    [W:2.758 / U:0.456 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site