[lkml]   [1999]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: User vs. Kernel (was: To be smug, or not to be smug, that is the
    Steven Roberts writes:
    > "Albert D. Cahalan" wrote:
    >> Henrik Olsen writes:
    >>>>> "Albert D. Cahalan" <> writes:

    >>>>>> Blocking system calls were a bad idea. Signals were added to unix
    >>>>>> to address the lack of a general event queue. Since longjump won't
    >>>>>> get you out of one of those crummy blocking system calls, some
    >>>>>> fool made signals interrupt system calls. As a patch on top of
    >>>>>> a patch on top of a patch, app programmers need to wrap system
    >>>>>> calls in loops. Patching the brokenness even more, we see Netscape
    >>>>>> talking to itself to get around a stupid race condition. Since
    >>>>>> the unixy API does not support dispatching concurrent system calls,
    >>>>>> someone added the aio_* functions to "fix" it for the limited case
    >>>>>> of simple disk IO. All along the way people find hacks for their
    >>>>>> own immediate problem rather than fixing the API.

    > I personally like blocking system calls. They fit in far better
    > for the application model I use. We have multiple threads,
    > and it is easier to block. We in fact don't use the non blocking
    > I/O calls in win32 because it is easier for us at least to use
    > blocking ones. Yes, async IO can be nice for certain things, but
    > saying blocking system calls are a bad idea is crap.

    Don't tell me you _like_ interrupted system calls...

    Threads change everything. How would you like a new thread
    whenever a signal arrives? That could be an alternate fix.

    >> If someone with great vision and design skills wants to create a
    >> new API for Linux, we should seriously consider such a proposal.

    > I think this kind of boils down to user vs. kernel API issues.
    > why not great this all new wonderful API set in a user space lib?

    Ha, ha, ha. NO.

    As a prototype, maybe. It would be an extraordinary kludge.
    It would have all the crappyness of user-space threads and worse.

    > I really like that the
    > kernel API in linux is small compared to the kernel API in win32. I
    > quite a bit about the win32 API, but the most important thing I know, is
    > that it is a big ugly mess, and I don't think linux should head in that
    > direction.

    No, the native NT kernel API is very simple. (it is not Win32)

    > I still like the old principle, of if you can do it in user space, then
    > do it in user space.

    How about "do it in the best place" instead? Often that place is
    a library, but don't get religious about it.

    In this case, the kernel API itself could use some adjustments.
    Emulating that in userspace is a sick joke.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:49    [W:0.025 / U:0.092 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site