3 ms·
One note, the message queue has a limit in size,going over the limit will drop messages.
by Fire-Dragon-DoL 4y ago
One note, the message queue has a limit in size,going over the limit will drop messages.
- toast0 4y agoIf there's a limit, it's new and I can't find it in a quick search; I did find a 2014 PR that was rejected because dropping messages violates core semantics, IMHO killing the recipient would be OK though. Traditionally it's unbounded, but when you exhaust the memory of the host (or the ulimit, if set), you'll likely loose the whole VM.
- Fire-Dragon-DoL 4y agoTurns out it was specific to the application I worked on, sorry for the misinformation. It is configurable: https://www.erlang.org/eeps/eep-0042 https://www.erlang.org/eeps/eep-0042
- toast0 4y agoEEP 42 is not implemented in mainline OTP. If it were, the proposal would likely link to the implementation, and the EEP index in EEP 0 would show what version it was first included in: https://www.erlang.org/eeps/eep-0000 https://www.erlang.org/eeps/eep-0000 If your application is using something like this, you're running a modified beam (which is fine; my professional experience is on a modified beam where we added a process_info option to drop all messages in the queue of a given process, and to allow for messages to be added to the front of the queue, neither of which would be acceptable upstream, but both of which were super handy for us)
- Fire-Dragon-DoL 4y agoIt's been a long time, so i could be wrong, but I remember we did face the problem at some point. Either way, not having a limit makes it even easier to use, which I really appreciate