interprocess inlining

[Sven-Olof Nystr|m]

Thomas Lindgren writes:
 > > [exceptions in another process]
 > There is another book keeping issue as well:
 > primitives such as self(), process dictionary, etc.
 > must be changed while you are executing the code of
 > the other process. Likewise with the set of links,
 > monitors, and possibly other things. (Alternatively,
 > you can restrict yourself to not inlining such code.)

Yes. Most primitives need to be rewritten to allow external
execution. (This is pointed out in the paper.)


 > 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.

 > 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. 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.


Sven-Olof Nyström