> In BoC, the equivalent of a message is received by multiple actors and operates with exclusive access to the message and all of the receivers.
(emphasis mine)
IIUC with actors, messages are processed by exactly one actor so it can be difficult to express transactions (e.g. transferring funds from A to B cannot be done atomically). Erlang somewhat fixes this with "selective receive" which re-introduces the possibility of deadlocks. BoC fixes both issues.
Was wondering how this is using a separate GIL per action when the actions are pure Python code. "PEP 684 introduces a per-interpreter GIL, so that sub-interpreters may now be created with a unique GIL per interpreter."
8 comments
[ 2.6 ms ] story [ 28.8 ms ] threadWhy would one ever result at that methodology?
I still don't really see behaviors helping with this. Like yeah you avoid deadlocking, but now you're abstracting away mutexes :S
> In BoC, the equivalent of a message is received by multiple actors and operates with exclusive access to the message and all of the receivers.
(emphasis mine)
IIUC with actors, messages are processed by exactly one actor so it can be difficult to express transactions (e.g. transferring funds from A to B cannot be done atomically). Erlang somewhat fixes this with "selective receive" which re-introduces the possibility of deadlocks. BoC fixes both issues.