| This point: "CSP message-passing fundamentally involves a rendezvous between the processes involved in sending and receiving the message, i.e. the sender cannot transmit a message until the receiver is ready to accept it." it not that strict in a practice. In dependency of implementation of CSP there can be CSP-channels with limited and unlimited capacity. If channels with limited capacity are used then some kind of rendezvous is necessary only on attempt to write a new message to a full channel. In that case process-writer will be blocked until process-reader read some messages from the channel. If size-unlimited channels are used then interaction of CSP-processes will be asynchronous (just like in Actor Model). There is another important difference (but it also depends on implementation details): CSP-processes are always proactive. They can do something even if there is no messages to read and process. Otherwise actors are reactive (usually). They react only to incoming messages and do nothing if there is no new message in they inboxes. This especially true for cases when actors are implemented as objects with callbacks (for example it is true for Akka, CAF, SObjectizer, QP/C++, Orleans and so on). But there can be implementations of Actor Model where an actor has to call some kind `receive` primitive to get an incoming message. For example it is Erlang programming language and Just::Thread Pro Actor Edition library for C++. |