The BEAM will totally interrupt a process that is currently processing a message. It does so based on a 'reduction' count, roughly equivalent to each function c

The BEAM will totally interrupt a process that is currently processing a message. It does so based on a 'reduction' count, roughly equivalent to each function call. Since there is no looping construct, any iteration can be interrupted halfway through. But this means that the VM is entirely allowed to interrupt you halfway through a call to sorting a list obtained through a message. No qualms about it. You reach you function call limit, you're phased out and put back in the queue. The three ways I know about to hog a scheduler for yourself are: - write C code that misbehaves and stalls the scheduler (there is now a dirty scheduler if you want the code to run there) - hardcode a sequence of arithmetic operations (which are not subject to reduction counts) that can take a very long time to execute -- something that never happens naturally in code - set your process to the max priority and do busy looping while the rest of the system is at a lower priority. Your process will now have a higher priority and prevent others from running That's about what you can do. It requires a kind of explicit effort to do and is very easy to spot from afar.