[rdtsc]

Yes.

In Erlang:

    exit(kill).

or exit(Pid,kill).

Will kill a process. It has an isolated heap, so it won't affect other (possibly hundreds of thousands of) running processes. That memory will be garbage collected, safely and efficiently.

This will also work in Elixir, LFE and other languages running on the BEAM VM platform.

EDIT: masklinn user below pointed out correctly, the example is exit/2, that is exit(Pid,kill). In fact it is just exit(Pid, Reason), where Reason can be other exit reason, like say my_socket_failed. However in that case the process could catch it and handle that signal instead of being un-conditionally killed.

[bluejekyll]

This is called from within a threads execution, right? I think the question is about being able to kill a thread externally.

Java had this in 1.0 or 1.1 and then thought better of it and deprecated the API.

[masklinn]

> This is called from within a threads execution, right? I think the question is about being able to kill a thread externally.

Yes the GP has the wrong arity, exit/1 terminates the current process but exit/2[0] will send an exit signal to an other process and possibly cause them to terminate (depending on the provided Reason and whether they trap exits).

This is a normal behaviour of Erlang which enables things like seamless supervision trees, where exit signals propagate through the supervision trees reaping all of the processes until they encounter a process trapping exits and a supervisor can freely terminate its children[1]

This can work because erlang doesn't have shared state[2][3], and BEAM implements termination signaling (so processes can be made aware by the VM of the termination of other processes)

[0] http://erlang.org/doc/man/erlang.html#exit-2

[1] http://erlang.org/doc/design_principles/sup_princ.html#id740...

[2] between processes, state is always owned by specific processes and queried/copied out across the process boundary

[3] and thus a process being terminated can't leave inconsistent state behind for others to corrupt themselves (or the VM itself) with

[felixgallo]

erlang also uses per-actor message queues and has a kill safe design philosophy, so it's not a problem.

[rdtsc]

It works correctly either way -- externally with exit(Pid,kill) or by the process itself as exit(kill). The last one is just a shorthand for exit(self(), kill). Where self() is the process id of the currently running process.

[masklinn]

> It works correctly either way

But the way you showed was not one in which anyone was interested, synchronous exceptions work in more or less every language, and you can't assume readers know your self-killing is actually implemented via asynchronous exceptions since they don't know the language.