Index: doc/theses/colby_parsons_MMAth/text/actors.tex
===================================================================
--- doc/theses/colby_parsons_MMAth/text/actors.tex	(revision 05956d21b283440532f252a1c679dc968168b993)
+++ doc/theses/colby_parsons_MMAth/text/actors.tex	(revision 60c3d87e3c00f8e5303153bdaebe7088085c2e8e)
@@ -7,5 +7,5 @@
 % C_TODO: add citations throughout chapter
 Actors are an indirect concurrent feature that abstracts threading away from a programmer, and instead provides \gls{actor}s and messages as building blocks for concurrency, where message passing means there is no shared data to protect, making actors amenable in a distributed environment.
-Actors are another message passing concurrency feature, similar to channels but with more abstraction, and are in the realm of \gls{impl_concurrency}, where programmers write concurrent code without dealing with explicit thread create or interaction.
+Actors are another message passing concurrency feature, similar to channels but with more abstraction, and are in the realm of \gls{impl_concurrency}, where programmers write concurrent code without dealing with explicit thread creation or interaction.
 The study of actors can be broken into two concepts, the \gls{actor_model}, which describes the model of computation and the \gls{actor_system}, which refers to the implementation of the model.
 Before discussing \CFA's actor system in detail, it is important to first describe the actor model, and the classic approach to implementing an actor system.
@@ -267,5 +267,5 @@
 % As part of packaging the envelope, the @?<<?@ routine sets a routine pointer in the envelope to point to the appropriate receive routine for given actor and message types.
 
-\subsection{Actor Send}\label{s:ActorSend}
+\subsection{Actor Send}\label{s:ActorSend} % C_TODO: rework this paragraph based on discussion with Mike, see ~/cfa-cc/actor_poly.tex for notes (and fangren's resolver changes)
 All message sends are done using the left-shift operator, @<<@, similar to the syntax of \CC's stream output.
 As stated, \CFA does not have named inheritance with RTTI.
@@ -340,5 +340,5 @@
 Since all messages to a given actor are in the same queue, this guarantees atomicity across behaviours of that actor since it can only execute on one thread at a time.
 After running a behaviour, the executor thread examines the returned allocation status from the @receive@ routine for the actor and internal status in the delivered message, and takes the appropriate action.
-Once all actors have marked themselves as being finished the executor initiates shutdown by inserting a sentinel value into the message queues.
+Once all actors have marked themselves as being finished the executor initiates shutdown by inserting a sentinel value into the message queues. % C_TODO: potentially change if I keep shutdown flag change
 Once a executor threads sees a sentinel it stops running.
 After all executors stop running the actor system shutdown is complete.
@@ -348,19 +348,7 @@
 Because a C program manages message lifetime, messages cannot be copied for each send, otherwise who manages the copies.
 Therefore, it up to the actor program to manage message life-time across receives.
-However, for a message to appear on multiple message queues, it needs an arbitrary number of link fields.
+However, for a message to appear on multiple message queues, it needs an arbitrary number of associated destination behaviours.
 Hence, there is the concept of an envelop, which is dynamically allocated on each send, that wraps a message with any extra implementation fields needed to persist between send and receive.
 Managing the envelop is straightforward because it is created at the send and deleted after the receive, \ie there is 1:1 relationship for an envelop and a many to one relationship for a message.
-
-% In actor systems, messages are sent and received by actors.
-% When a actor receives a message it executes its behaviour that is associated with that message type.
-% However the unit of work that stores the message, the receiving actor's address, and other pertinent information needs to persist between send and the receive.
-% Furthermore the unit of work needs to be able to be stored in some fashion, usually in a queue, until it is executed by an actor.
-% All these requirements are fulfilled by a construct called an envelope.
-% The envelope wraps up the unit of work and also stores any information needed by data structures such as link fields.
-
-% One may ask, "Could the link fields and other information be stored in the message?".
-% This is a good question to ask since messages also need to have a lifetime that persists beyond the work it delivers.
-% However, if one were to use messages as envelopes then a message would not be able to be sent to multiple actors at a time.
-% Therefore this approach would just push the allocation into another location, and require the user to dynamically allocate a message for every send, or require careful ordering to allow for message reuse.
 
 Unfortunately, this frequent allocation of envelopes for each send results in heavy contention on the memory allocator.
@@ -397,5 +385,5 @@
 The next time 19 messages are enqueued, the array size is doubled to 36!
 To avoid this issue a second check is added.
-Each copy queue started tracking the utilization of its array size.
+Each copy queue now tracks the utilization of its array size.
 Reclamation only occurs if less than half of the array is utilized.
 In doing this, the reclamation scheme is able to achieve a lower high-watermark and a lower overall memory utilization compared to the non-reclamation copy queues.