4 ms·
The BEAM scheduler is not quite preemptive as I understand it, but in practice it gets close because instead of yield points being defined manually with “await”
by jolux 6y ago
The BEAM scheduler is not quite preemptive as I understand it, but in practice it gets close because instead of yield points being defined manually with “await” they are inserted automatically when you return from a function or call a function or do some number of other fundamental operations, and the pure functional nature of the language means that functions are short and consist almost solely of other function calls.
- sa1 6y agoThat is how haskell's scheduler works, but I was not aware that it was the same with BEAM. Makes sense.
- jolux 6y agohttps://blog.stenmans.org/theBeamBook/#_reductions https://blog.stenmans.org/theBeamBook/#_reductions
- dmm 6y agoA favorite HN comment that discusses this: https://news.ycombinator.com/item?id=13503951 https://news.ycombinator.com/item?id=13503951 Go read it all but here's a relevant quote: """ So how does Erlang ensure that processes don't hog a core forever, given that you could theoretically just write a loop that spins forever? Well, in Erlang, you can't write a loop. Instead of loops, you have tail-calls with explicit accumulators, ala Lisp. Not because they make Erlang a better language to write in. Not at all. Instead, because they allow for the operational/architectural decision of reduction-scheduling. """
- jolux 6y agoThat is a fantastic comment. I also recommend the BEAM book to those who want to go deeper: https://blog.stenmans.org/theBeamBook/ https://blog.stenmans.org/theBeamBook/ I haven’t finished it yet but the chapters on scheduling are great.
- dmitriid 6y agoThere's also BEAM Wisdoms: http://beam-wisdoms.clau.se/en/latest/ http://beam-wisdoms.clau.se/en/latest/
- k__ 6y agolol, so BEAM is for schduling like Rust is for memory allocation?