inter-process inlining

[Jim Larson]

In message <Pine.GSO.4.44.0211300022230.23417-100000@REDACTED> you write:
>
>Just a thought that came to me while driving home.
>
>The EUC talk "On reducing interprocess overhead
>communication in concurrent programs" mentioned the idea of
>inlining, where a client process could (in some cases)
>directly fetch the server's state and perform the operation
>needed without context switching.
>
>Perhaps it's mentioned somewhere in the paper, but what
>happens if there is a bug in the server code, and it
>crashes?

The paper doesn't appear to mention it.

Along the same lines, some runtime mechanism would have to watch
for hot-loading of the server's code modules and dynamically
"recompile" the client's inlined code.  The paper doesn't mention
this explicitly, but it does propose an auxiliary process that looks
for optimization opportunities in the running system - this could
be extended to handle module replacement as well.

>Would the normal error indication be simulated even with
>inlining, or would there be an entirely different error?

You certainly *could* simulate the usual error behavior with inlining
- you just have to be careful that the costs of this fidelity don't
eliminate the benefits of inlining.

Since, presumably, the errors are rare and not performance-critical,
a clever implementor could make the non-error case faster at the
expense of needing more work to generate the correct error message.

Jim Larson
jim@REDACTED