inter-process inlining

[Ulf Wiger]

On Tue, 3 Dec 2002, Sven-Olof Nystr|m wrote:

>About exceptions. (I assume that crash = throw an
>exception. Are there any other types of crashes that should
>be considered?)

No... I think. Handling exceptions is probably enough.

>This question is trickier. As far as I know, Happi has not
>addressed this issue directly. There are two issues that
>need to be handled. First, the exceptions must somehow be
>caught, as they cannot be allowed to affect the client
>process. Second, the exception must be reproduced on the
>server, either immediately or when the server is scheduled.

If the exception is reproduced later, it must still be so
that the server actually acts on that very message (and
perhaps this isn't appropriate if other messages have come
in to the server during the scheduling delay, since a
selective receive might have resulted in a different
prioritization of messages then -- unlikely, but...)


>Since we want optimized code to behave 'as if' the
>optimization hadn't happend, we want the server code to
>throw the exception it would have thrown originally. If the
>inlined code does not contain any side-effects, the
>solution is simple: pretend that the optimization never
>happend and that the inlined code was never executed. Just
>leave the server in its current state, insert the message
>in the mailbox and let the client continue its execution.
>When the server is scheduled, it will (eventually) throw
>the exception.

The most appropriate would perhaps be to schedule the server
immediately (see above). Doing it this way would also ensure
that the stack chain on the server reflects the situation
appropriately.

>If the in-lined code contains side-effects things get
>slightly more complicated. The simplest solution is to
>avoid this problem by only inlining code that does not have
>side-effects (this is probably a very reasonable
>restriction).

Yes, it seems reasonable.


>If we inline code with side effects, and code following a
>side-effect throws an exception, one way of reproducing the
>exception is to put the server in a state corresponding to
>a point in the program after the side-effect and before the
>instruction causing the exception.

Hmm...


/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson Telecom AB, ATM Multiservice Networks