5 ms·

The BEAM is a preemptive VM. That means that no one long running process can hog resources. The BEAM was built on a principal of responsiveness since it was or

The BEAM is a preemptive VM. That means that no one long running process can hog resources. The BEAM was built on a principal of responsiveness since it was originally designed for telephonics. Here's an in depth article on preemption in the BEAM that I shared with a friend this morning https://hamidreza-s.github.io/erlang/scheduling/real-time/preemptive/migration/2016/02/09/erlang-scheduler-details.html https://hamidreza-s.github.io/erlang/scheduling/real-time/pr...

misterbowfinger 8y ago
Nice, I'll check it out!
dozzie 8y ago
> The BEAM is a preemptive VM. The BEAM Book shared by armitron disagrees: https://happi.github.io/theBeamBook/#_scheduling_non_preemptive_reduction_counting https://happi.github.io/theBeamBook/#_scheduling_non_preempt... Though an Erlang programmer never sees this in practice, because compiler inserts yield points appropriately.
- deleted 8y ago
  [deleted]
- davydog187 8y ago
  Maybe on the definition of "preemptive", but it should be treated as a preemptive VM in practice.
  - derefr 8y ago
    Nah. You can screw with the BEAM’s reduction-scheduling even in pure Erlang code: just write a really long function body consisting only of arithmetic expressions (picture an unrolled string hash function.) Since it contains no CALL or RET ops, the scheduler will never hit a yield point, even after going far “into the red” with the current process’s reduction budget. You just never see this in real Erlang code, because who would code that way? If you want to be idiomatic, use recursion. If you want to be fast, use a NIF. Why ever use an unrolled loop body? But it can happen, and therefore, the BEAM does not guarantee preemption, even in Erlang. Reduction scheduling isn’t a “kind of” preemptive scheduling. It’s its own thing.
    - davydog187 8y ago
      I mean, like i said, it should be treated as a preemptive VM in practice. In reality its not, but for most practical cases, its easier to understand it terms of preemption.
      - derefr 8y ago
        As a developer, yes. As an ops person trying to figure out why your deployed release isn’t making its deadlines, no.
PaulHoule 8y ago
I want that. I hate looking at spinners on my computer because some software is hung up here or there. I am prototyping a "desktop" search application which hits a number of sources and interacts with them by their protocol (maybe it gets full hits from bing but just gets identifiers from pubmed and has to look up the identifiers) This can never show a spinner but instead keep the UI live all the time, filling in results as soon as they become available. I have been looking at asyncio in Python and it is an unholy mess. Just as Java was the first environment to be really threadsafe (eg. the found the memory model of C underlying it was screwed and implemented the first sound memory model) BEAM seems to be the first environment designed with responsiveness in mind.
- com2kid 8y ago
  The WinRT environment enforces non-blocking async. Any operation in the library that can take time is async. Async is everywhere. I've always worked on embedded UIs where we had a physical watchdog timer (an independent chip power cycles your main device if a keep alive function isn't called periodically) that was set to ~30ms. In test, anything running longer than 30ms had to be broken up. The entire system was written in C and C++. The lesson is you can write responsive apps in any language, but the entire underlying stack needs to cooperate. IIRC WinRT's requirement for "async" is operations that take more than 1 second. I disagree with that, I'd set the limit at 100ms, but I guess that'd annoy programmers even more. :)
  - PaulHoule 8y ago
    I think WinRT is a non-starter for two audiences. (1) People who know windows will find it hard to switch to the async model (2) People who don't know windows will have access to a disorientingly large API
- tomsmeding 8y ago
  To be fair, Python asyncio is a really ugly interface for something that other languages (e.g. JS and others) have done a lot better. Maybe look at other languages than Python for async programming.

misterbowfinger 8y ago

Nice, I'll check it out!

dozzie 8y ago

> The BEAM is a preemptive VM. The BEAM Book shared by armitron disagrees: https://happi.github.io/theBeamBook/#_scheduling_non_preemptive_reduction_counting https://happi.github.io/theBeamBook/#_scheduling_non_preempt... Though an Erlang programmer never sees this in practice, because compiler inserts yield points appropriately.

deleted 8y ago
[deleted]
davydog187 8y ago
Maybe on the definition of "preemptive", but it should be treated as a preemptive VM in practice.
- derefr 8y ago
  Nah. You can screw with the BEAM’s reduction-scheduling even in pure Erlang code: just write a really long function body consisting only of arithmetic expressions (picture an unrolled string hash function.) Since it contains no CALL or RET ops, the scheduler will never hit a yield point, even after going far “into the red” with the current process’s reduction budget. You just never see this in real Erlang code, because who would code that way? If you want to be idiomatic, use recursion. If you want to be fast, use a NIF. Why ever use an unrolled loop body? But it can happen, and therefore, the BEAM does not guarantee preemption, even in Erlang. Reduction scheduling isn’t a “kind of” preemptive scheduling. It’s its own thing.
  - davydog187 8y ago
    I mean, like i said, it should be treated as a preemptive VM in practice. In reality its not, but for most practical cases, its easier to understand it terms of preemption.
    - derefr 8y ago
      As a developer, yes. As an ops person trying to figure out why your deployed release isn’t making its deadlines, no.

PaulHoule 8y ago

I want that. I hate looking at spinners on my computer because some software is hung up here or there. I am prototyping a "desktop" search application which hits a number of sources and interacts with them by their protocol (maybe it gets full hits from bing but just gets identifiers from pubmed and has to look up the identifiers) This can never show a spinner but instead keep the UI live all the time, filling in results as soon as they become available. I have been looking at asyncio in Python and it is an unholy mess. Just as Java was the first environment to be really threadsafe (eg. the found the memory model of C underlying it was screwed and implemented the first sound memory model) BEAM seems to be the first environment designed with responsiveness in mind.

com2kid 8y ago
The WinRT environment enforces non-blocking async. Any operation in the library that can take time is async. Async is everywhere. I've always worked on embedded UIs where we had a physical watchdog timer (an independent chip power cycles your main device if a keep alive function isn't called periodically) that was set to ~30ms. In test, anything running longer than 30ms had to be broken up. The entire system was written in C and C++. The lesson is you can write responsive apps in any language, but the entire underlying stack needs to cooperate. IIRC WinRT's requirement for "async" is operations that take more than 1 second. I disagree with that, I'd set the limit at 100ms, but I guess that'd annoy programmers even more. :)
- PaulHoule 8y ago
  I think WinRT is a non-starter for two audiences. (1) People who know windows will find it hard to switch to the async model (2) People who don't know windows will have access to a disorientingly large API
tomsmeding 8y ago
To be fair, Python asyncio is a really ugly interface for something that other languages (e.g. JS and others) have done a lot better. Maybe look at other languages than Python for async programming.