Messages in this thread | | | Date | Mon, 21 Jun 1999 11:07:41 -0700 | From | "Jeffrey B. Siegal" <> | Subject | Re: 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 benefit.
- 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/
| |