Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Clarify expectations when passing mutable data in messages for each ActorSystem #7
Two major selling points for me on Thespian have been (1) supporting distributed concurrency transparently and (2) keeping actors truly atomic/private (apologies as I'm probably not using the correct technical terminology).
When considering users who are reading docs and comparing Thespian to other actor system implementations, I think it is helpful to differentiate on these two points in the docs explicitly. The first is already pretty clear, I think. For the second, compare to this statement in the Pykka docs:
With some reasoning, one can figure out when Thespian would probably behave like this (simpleSystemBase) and when it wouldn't (the others), but I think a note at a higher level of abstraction would be good. That is, this statement:
Implies that mutable data structures are probably being passed around instead of copied or pickled, but you could certainly still be doing the copying/pickling in this implementation.
A silly test:
This does raise the question as to whether this is a "bug" in simpleSystemBase, since, if it is used mostly for testing, wouldn't it be desirable to keep its behavior as close to the other systems as possible?
Thank you for identifying this lack of clarification.
I have updated the documentation (9bd0801) to reflect the current behavior.
Thespian actually takes the same stance as Pykka (no automatic copying for performance reasons) but as you noted, there are differences based on which system base is used. For the multiprocess bases in your example above, the original is not modified because the TestActor runs in a separate process, so it does get copies of the message by virtue of it having been serialized and transmitted to that process.
Your point regarding behavior differences is a good one. At the moment, I'm inclined to keep the behavior as is because the simpleSystemBase is the least safe and therefore most likely to expose issues, which is desirable for testing. Please feel free to provide arguments to the contrary if you think this is the wrong position on this situation.
Looks good to me.
The only argument I have for changing the behavior of simpleSystemBase considers the novice/misguided user. They may try to abuse the ability to continue referencing sent data in the simpleSystemBase, and because of this I worry that someone might develop a working implementation that tests well early on, only to find out later that they need to change their approach significantly.
I think it's fine to leave as-is, and tackle the problem through education/documentation should it come up. If, however, every other posting to the google group becomes "why isn't my code working" and this is the problem, then reconsider the simpleSystemBase implementation.