interprocess inlining

[Thomas Lindgren]

--- Sven-Olof Nystr|m <svenolof@REDACTED> wrote:
> Thomas Lindgren writes:
>  > > [exceptions in another process]
>  > [rewrite primitives that refer to process state]
> 
> Yes. Most primitives need to be rewritten to allow
> external execution. (This is pointed out in the 
> paper.)

OK, I missed that. Sorry.

>  > Second: it seems that the restriction that A may
> not
>  > suspend while executing code from B is fairly
>  > draconian: you can't, in principle, make a
> procedure
>  > call inside the inlined code (p.5, top) since
> that
>  > increments the reduction counter in ordinary
> BEAM. Or
>  > am I missing something?
> 
> No. Besides the problem with reduction counters,
> there is also the
> problem that any code executed externally (by
> another process) must be
> adapted for external execution. If inlined code
> contains a procedure
> call, then the call should be to a version of the
> procedure adapted
> for external execution. To execute a call externally
> also requires the
> client (A) to allocate a stack frame on the server's
> (B's) stack. This
> is certainly doable, but adds to the complexity of
> the optimization.

The first part sounds okay; duplicating code is what
inlining is about. Switching stacks sounds hairier, as
you say. And that's ignoring suspension, of course.

>  > Third: another interesting issue, if we want to
> handle
>  > more complex scenarios, is how to handle chained
>  > sends:
>  > 
>  > - A sends to B
>  > - B sends to C
>  > - C sends to D
>  > 
>  > (perhaps C or D are really A; perhaps we suspend
> in
>  > code belonging to C; etc.)
> 
> The situation when B sends a message back to A is
> discussed in the
> paper (a rather interesting special case, I think).
> The case when B
> sends a message to a third process is not really
> that hard. The send
> is just another primitive. To run the send
> externally, we need a
> version adapted for external execution. 

I assume we are talking about inlining the subsequent
sends as well here? In that case, I think there's a
bit more to it. 

In practice, one would have to handle possible
suspension inside B, for example. Also, checking what
sends are really "return sends" and to where. (A sends
to B, which sends to C, which replies to A, say.)
Perhaps there are more issues to consider.

(It should be said it's always possible to limit what
is handled; but we must then ask which are the common
cases.)

> This assumes that everything goes well. 
> The case when B's code contains a send
> followed by some
> code that throws an exception is left as an exercise
> for the reader.

Alas, this mail, at least, is too short to hold the
solution :-)

Best,
Thomas


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com