[lkml]   [1999]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Some very thought-provoking ideas about OS architecture.
    > Batching messages between processes can be good, but what percentage of the
    > time is this practical? In most robust applications you tend to need the
    > result of one step before you are sure what the next step is, due to errors,
    > etc. There are obvious exceptions. I could initiate a bunch of writes to
    > different places, and look at all the results in one go.

    To work this requires the interface be designed to avoid the need for
    round trips (returned results). For example, X11 protocol is designed
    to need relatively few results. Rather than returning, say, a window
    ID, the client passes a window ID to the server which uses that ID to
    identify the window in subsequent requests. So rather than:

    CreateWindow() ->

    <- WindowID

    OperateOnWindow(WID) ->

    You have

    CreateWindow(WID) ->
    OperateOnWindow(WID) ->

    In this case, CreateWindow and OperateOnWindow can clearly be batched
    into a single message. Failures are reported back asynchronously (the
    equivalent in a system call context would be a signal); on the rare
    occasion that the client really needs to know whether an operation
    succeeded, it can do so by forcing a round trip. Generally, it doesn't
    matter and this overhead is avoided.

    Without redesigning the Unix-derived system call interface to use
    similar techniques, I don't see how this would yield any significant

    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:52    [W:0.019 / U:61.936 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site