3 ms·

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

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.
- ProfHewitt 7y ago
  Erlang has been used for many important practical practical implementations :-) However, we need much better tools to implement Reusable Secure Intelligent Systems by 2030! See the following for some ideas: https://papers.ssrn.com/abstract=3428114 https://papers.ssrn.com/abstract=3428114
toast0 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. Indeed, Erlang does not have a way to induce a catchable exception into a process stack from outside the process. Processes are isolated, and the way that processes interact with the world is through their mailbox. The Erlang way (TM) is to let your processes crash (or be killed), but be supervised and restarted, and the new process will handle whatever state the world is in, and bring it to a good state (or it won't, and it will die, and the supervisor will die, and the system will restart, eventually). You could certainly pepper you code with something like receive cancel -> throw cancel after 0 -> ok end In places where you might want to be cancelled, and send a cancel message as appropriate, to get something like what you're asking. But it wouldn't feel very Erlangy, and looking at the results of being explicit about everywhere you might want to be cancelled might lead you towards the premise of Let it Crash. There are a million and one ways that the system might fail during activity, and for most of them, the right thing to do is restart, pick up the pieces, and go forward from there if you can. You're going to have to handle that anyway in case of unexpected restarts due to hardware or software faults. > 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. What do you mean by a processor here. Like a separate CPU, or is this a process / thread? What is the relationship between this processor and the code, and the run request? What behavior is changing in this example? > 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. That Erlang programs often use processes to hold state is not a deficiency; that's how Erlang models the world. State is intended to be held in processes, and the way that they do that is through tail call recursion on the explicit state. Although, sometimes, some state is stored in the process dictionary (which is essentially a key-value store) or in ETS/Mnesia, which can be modeled as a process (but is implemented as shared memory), or in state held outside of Erlang (such as the filesystem, or other programs). If you don't like the world model where state is held in processes, Erlang clearly isn't for you; but I find it's a model that fits well with distributed systems, and allows for complex systems to be built with small teams.
- ProfHewitt 7y ago

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.

ProfHewitt 7y ago
Erlang has been used for many important practical practical implementations :-) However, we need much better tools to implement Reusable Secure Intelligent Systems by 2030! See the following for some ideas: https://papers.ssrn.com/abstract=3428114 https://papers.ssrn.com/abstract=3428114

toast0 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. Indeed, Erlang does not have a way to induce a catchable exception into a process stack from outside the process. Processes are isolated, and the way that processes interact with the world is through their mailbox. The Erlang way (TM) is to let your processes crash (or be killed), but be supervised and restarted, and the new process will handle whatever state the world is in, and bring it to a good state (or it won't, and it will die, and the supervisor will die, and the system will restart, eventually). You could certainly pepper you code with something like receive cancel -> throw cancel after 0 -> ok end In places where you might want to be cancelled, and send a cancel message as appropriate, to get something like what you're asking. But it wouldn't feel very Erlangy, and looking at the results of being explicit about everywhere you might want to be cancelled might lead you towards the premise of Let it Crash. There are a million and one ways that the system might fail during activity, and for most of them, the right thing to do is restart, pick up the pieces, and go forward from there if you can. You're going to have to handle that anyway in case of unexpected restarts due to hardware or software faults. > 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. What do you mean by a processor here. Like a separate CPU, or is this a process / thread? What is the relationship between this processor and the code, and the run request? What behavior is changing in this example? > 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. That Erlang programs often use processes to hold state is not a deficiency; that's how Erlang models the world. State is intended to be held in processes, and the way that they do that is through tail call recursion on the explicit state. Although, sometimes, some state is stored in the process dictionary (which is essentially a key-value store) or in ETS/Mnesia, which can be modeled as a process (but is implemented as shared memory), or in state held outside of Erlang (such as the filesystem, or other programs). If you don't like the world model where state is held in processes, Erlang clearly isn't for you; but I find it's a model that fits well with distributed systems, and allows for complex systems to be built with small teams.

ProfHewitt 7y ago