3 ms·

The code is just binary code, which can only be run. The Actor implementation of a Controller just runs the code and so the controller does not have to itself

The code is just binary code, which can only be run. The Actor implementation of a Controller just runs the code and so the controller does not have to itself perform a become. The variables currentVersion and the crowd running hold the state of the changing behavior of the controller. A tricky part for Erlang is that the variable running must updated even if code.run is cancelled.

toast0 7y ago
The Erlang version doesn't need to become to run code either. It is just a fun thing to do. It's straightforward to just run the code as well; if you get a function F, you just do F(), assuming the function has no arguments, because you didn't include any; you can also use erlang:apply(F, Args), if you had passed a list of arguments. Honestly, I think we're going back and forth here, because we're not speaking the same language. I don't know what a crowd is, and I don't know what cancelled means. Those aren't concepts in Erlang. I'm not sure if you mean to have a distinction between 'boot' and 'run', you're using them both, and I think to mean the same thing you send a boot request when you want to run a piece of signed code? Erlang is foundationally about independent processes with ordered mailboxes. The two ways to interpret cancel in Erlang would be a) send a message 'cancel', and hope the process receives it before completing the work, or b) kill the process. A process can set a flag so that most kills will be turned into sending a message, but there's also an untrappable kill. Processes can also be linked and/or monitored for propagation of kills. You would typically model something with state like this as a process. The process would essentially be looping on a single function, passing any state it needed to keep to itself. In this case, you'd send it a boot request with the code to run etc, and your process id and a reference to get a response, and potentially a cancellation request, and maybe a get current version, and get running status (you didn't spec it, but they're both useful). The state in this case, that would be the current version, the public key, the current boot request (if any), and tracking details for the asynchronous signature checking, and tracking the running of the code. If you want to be able to kill the running code, without killing this process that has the state, then you'd need to spawn a new process to run the code, and you'd track that. If you don't really need that, you could just run the code in this process, and when it returns send back a result.
- ProfHewitt 7y ago
  Erlang can kill a process, but does not have cancellation, which causes a process to be halted and throw a cancellation exception from the point at which it was halted so that clean up can be performed while unwinding. Crowds are a way to keep track of processes performing activities so that they can be cancelled, etc. A boot request is sent to a controller to boot up a processor returning a termination report. A run request is sent to code to run returning a value. The Erlang approach to implementing behavior change by recursing on a single procedure passing the variables in a tail call has issues implementing holes in regions of mutual exclusion similar to ones encountered in JavaScript. Because tail calls with state variables do not always work and Erlang does not have an assignment command, Erlang programs often use helper processes to temporarily hold state. The above Actor implementation illustrates how the above interact in a way that can make Erlang implementations more complicated. Such interactions are common in implementing intelligent systems.
  - dnautics 7y ago
    > Erlang can kill a process, but does not have cancellation, which causes a process to be halted and throw a cancellation exception from the point at which it was halted so that clean up can be performed while unwinding. Typically you implement the callback terminate/2 in a genserver. If the process is hopelessly locked, you don't get to do the cleanup you want. It's usually not a big deal, though, because your processes are usually "owner in name only" for any given contentious resource, and a well-designed interface to a contentious resource uses what erlang aptly calls "resources", that lets the VM itself manage cleanup when the owning process dies. In the end, this leads to cleaner code, because you don't even have to worry about cleaning up (I almost never clean up tcp sockets, SSH connections, or file descriptors, because the VM does it for me and knows exactly when to do it). I am writing a native code interface, and the same can easily go from a non-erlang OS thread, by hooking in the correct "resource" adapters, I can have OS thread lifecycle well-managed by the already robust OTP system. > Erlang does not have an assignment command, Erlang programs often use helper processes to temporarily hold state. It actually kind of does. For the sorts of things you seem to be talking about, there is a process-bound k/v store that you can use to sneak some statefulness in. It's totally not talked about much because it's dangerous, especially for beginners, but it's useful when you know that the lifetime of your value is specifically bound to the lifetime of the process. In Elixir, this process k/v store is used, for example, to register in a side channel a "callers" and "ancestors" tree; when you're running tests, this lets you for example, run concurrent database tests transparently associated with the test process, that are also associated with a database transaction, so you can have concurrent database actions which are sandboxed to their own view of the universe. Some libraries even let you encode this into an http request so that your request can leave the VM, return back into the VM, and maintain its sandbox id and database association on the other side of the request. All of this is managed with about two lines of code provided out of the box in the gold standard database library. Prof Hewitt: I don't think erlang is a "true actor system" but I think it's much easier to code without errors than you may think.

toast0 7y ago

The Erlang version doesn't need to become to run code either. It is just a fun thing to do. It's straightforward to just run the code as well; if you get a function F, you just do F(), assuming the function has no arguments, because you didn't include any; you can also use erlang:apply(F, Args), if you had passed a list of arguments. Honestly, I think we're going back and forth here, because we're not speaking the same language. I don't know what a crowd is, and I don't know what cancelled means. Those aren't concepts in Erlang. I'm not sure if you mean to have a distinction between 'boot' and 'run', you're using them both, and I think to mean the same thing you send a boot request when you want to run a piece of signed code? Erlang is foundationally about independent processes with ordered mailboxes. The two ways to interpret cancel in Erlang would be a) send a message 'cancel', and hope the process receives it before completing the work, or b) kill the process. A process can set a flag so that most kills will be turned into sending a message, but there's also an untrappable kill. Processes can also be linked and/or monitored for propagation of kills. You would typically model something with state like this as a process. The process would essentially be looping on a single function, passing any state it needed to keep to itself. In this case, you'd send it a boot request with the code to run etc, and your process id and a reference to get a response, and potentially a cancellation request, and maybe a get current version, and get running status (you didn't spec it, but they're both useful). The state in this case, that would be the current version, the public key, the current boot request (if any), and tracking details for the asynchronous signature checking, and tracking the running of the code. If you want to be able to kill the running code, without killing this process that has the state, then you'd need to spawn a new process to run the code, and you'd track that. If you don't really need that, you could just run the code in this process, and when it returns send back a result.

ProfHewitt 7y ago
Erlang can kill a process, but does not have cancellation, which causes a process to be halted and throw a cancellation exception from the point at which it was halted so that clean up can be performed while unwinding. Crowds are a way to keep track of processes performing activities so that they can be cancelled, etc. A boot request is sent to a controller to boot up a processor returning a termination report. A run request is sent to code to run returning a value. The Erlang approach to implementing behavior change by recursing on a single procedure passing the variables in a tail call has issues implementing holes in regions of mutual exclusion similar to ones encountered in JavaScript. Because tail calls with state variables do not always work and Erlang does not have an assignment command, Erlang programs often use helper processes to temporarily hold state. The above Actor implementation illustrates how the above interact in a way that can make Erlang implementations more complicated. Such interactions are common in implementing intelligent systems.
- dnautics 7y ago
  > Erlang can kill a process, but does not have cancellation, which causes a process to be halted and throw a cancellation exception from the point at which it was halted so that clean up can be performed while unwinding. Typically you implement the callback terminate/2 in a genserver. If the process is hopelessly locked, you don't get to do the cleanup you want. It's usually not a big deal, though, because your processes are usually "owner in name only" for any given contentious resource, and a well-designed interface to a contentious resource uses what erlang aptly calls "resources", that lets the VM itself manage cleanup when the owning process dies. In the end, this leads to cleaner code, because you don't even have to worry about cleaning up (I almost never clean up tcp sockets, SSH connections, or file descriptors, because the VM does it for me and knows exactly when to do it). I am writing a native code interface, and the same can easily go from a non-erlang OS thread, by hooking in the correct "resource" adapters, I can have OS thread lifecycle well-managed by the already robust OTP system. > Erlang does not have an assignment command, Erlang programs often use helper processes to temporarily hold state. It actually kind of does. For the sorts of things you seem to be talking about, there is a process-bound k/v store that you can use to sneak some statefulness in. It's totally not talked about much because it's dangerous, especially for beginners, but it's useful when you know that the lifetime of your value is specifically bound to the lifetime of the process. In Elixir, this process k/v store is used, for example, to register in a side channel a "callers" and "ancestors" tree; when you're running tests, this lets you for example, run concurrent database tests transparently associated with the test process, that are also associated with a database transaction, so you can have concurrent database actions which are sandboxed to their own view of the universe. Some libraries even let you encode this into an http request so that your request can leave the VM, return back into the VM, and maintain its sandbox id and database association on the other side of the request. All of this is managed with about two lines of code provided out of the box in the gold standard database library. Prof Hewitt: I don't think erlang is a "true actor system" but I think it's much easier to code without errors than you may think.