[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.062 / U:0.992 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site