This is the discussion that led to the summary at ActorsModel comparing actors with FlowBasedProgramming:
There are very close parallels between FlowBasedProgramming (FBP) and Actors. Communication between asynchronous processes is by way of InformationPackets (= messages) travelling across BoundedBuffer connections. So, just like Actors, FBP does not allow any process to be affected except by way of an incoming InformationPacket. In the implementation with which we have most experience, we did provide a "named global" facility, but because of the asynchronism of the system, this could only safely be used for read-only data. In practice it was mostly used for shared reference tables. Besides we told our programmers that GlobalVariablesAreBad!
Actors can receive messages from any sender; CSP processes must explicitly name the sending process.
FBP processes can only receive IPs from processes they are connected to ("acquaintances" in Actors terminology).
In actors, the acquaintance relation is asymmetric. A can "know about" B (so that B is an acquaintance of A) without B "knowing about" A. Is this true of FBP?
In FBP there is an additional level of indirection, so maybe A and B are not exactly acquaintances: A and B communicate via named ports, and the connection between an output port of A and an input port of B is defined (by the application builder) in a separate specification, so it is the application builder's responsibility to know whether B can handle A's output, and to connect transform processes in between if they are required. Connections are only one-way -- if A needs feedback from B, it must use a separate connection. The port mechanism is what gives FBP the attribute of ConfigurableModularity.
- I see, so an actor name (~= object reference) corresponds loosely to an input port name.
- Possibly a process name/port name combination. Port names only have to be unique within an asynchronous FBP component (still looking for a good name!). But then this would imply that a process with more than one input port was really multiple actors, which I feel is counter-intuitive.
- It's quite common in actor systems (and other systems) for a single logical component to have multiple interfaces. Sometimes these are called facets (but with a different meaning than in FacetPattern, so I'll stick to "interfaces" to avoid confusion). Strictly speaking, every interface is a separate actor, and the overall component should be called an "actor configuration".
- How would you code a "collate" "actor"? See figure 8-13 in http://www.jpaulmorrison.com/fbp/simpapp2.htm -- pm
- You would probably create an actor corresponding to C in the figure (call it a CollateMaker), and then request as many interfaces as needed from this CollateMaker. These requests would include any parameters such as the "key fields [...] specified to Collate by means of option IPs".
- Looking at the applications for Collate in http://www.jpaulmorrison.com/fbp/substrs.htm I suspect that it should work on higher-level stream objects rather than streams of raw messages. This allows more flexiibility in handling flow control.
- There was another thing I noticed on that page different from actors: "[...] we alluded above to the fact that components have to be reentrant if they are going to multithread with each other. Strange things happen if you try to multithread processes which are not reentrant!" In an actor system you'd have to work really hard to write an actor definition that had this kind of thread safety problem (you could do it by writing a buggy serializer, I suppose).
- Probably my point about re-entrancy is redundant when talking about more recent languages, unless one tries to store dynamic information in class variables (?). The concept of multiple threads executing the same code asynchronously was strange to a lot of people in those days... -- pm
- Here are some more questions about FBP intended to compare it with actors:
- Are port names FirstClass?
- Yes. The first implementation of FBP used port numbers instead of port names, and they were FirstClass also.
- If port names are FirstClass, are they opaque? Or is it possible to decompose/construct a port name into/from a process name, and a string or symbol identifying the port within that process?
- See above. A port name is a way of having the inside and the outside of an asynchronous FBP component communicate. You could treat the combination of process and port as a fully qualified port name, but then see the problem above.
- Is the specification of which processes can communicate static, or can it be changed at run-time? If it can be changed, then are there constraints on how it can change similar to the "laws of locality" in section VII of "Actors and Continuous Functionals" (see URL above)?
- Interesting question: the specification has been static in all implementations so far. Most of http://www.jpaulmorrison.com/fbp/compos.htm addresses this issue. It will be interesting to see if the "laws of locality" have come to similar conclusions! -- pm
- The description of mother/daughter processes, and of monitor processes, reminds me of the supervisor hierarchy in ErlangLanguage, but Erlang has taken this a lot further.
- My impression so far is that the typical programming style of actor languages is a lot more dynamic than FBP. Dynamic creation of actors is the rule rather than the exception.
- Must each BoundedBuffer be associated with a specific (producer, consumer) pair?
- Actually a 4-tuple: (producer, output port, consumer, input port). -- pm
- Is it possible to implement a guaranteed-fair merge of two streams of InformationPackets?
- [Yes, see figure 8.12 of http://www.jpaulmorrison.com/fbp/simpapp2.htm A "first-come, first-served" merge is a special case of a fair merge.]
- Maybe I shouldn't have called it "first-come, first-served". My point was that an IP being sent by A will arrive on the BoundedBuffer connection when the scheduler processes the 'send', or as soon as there is room, but the timing of this is not guaranteed relative to sends from B. However, so far, this was never an issue. If it had been become one, we could have implemented some kind of "fair-share" scheduling. -- pm
- Do the answers to the above questions characterize FBP, or can they vary between FBP systems?
- Ummm. FBP has been continuously evolving for 30 years. I would definitely add connections defined externally to the components, and probably InformationPackets. -- pm
Messages are buffered in the actor model; in CSP, the sender is delayed until it synchronizes with the receiver.
Messages are also buffered in FlowBasedProgramming.
Actors And Flow Based Programming Discussion