interprocess inlining

[Sven-Olof Nystr|m]

Thomas Lindgren writes:
 > >  > 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.

 wasn't. Yes, doing process inlining with a third process can
certainly complicate things a bit. In principle, cascading process
inling should be like inlining any other operation. It is certainly
easy to come up with scenarios when we would run into difficulties,
though.


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

Agreed.


Sven-Olof