4 ms·
Go could have provided message queues with priorities Erlang style or something closer native solutions in Linux/Max/Windows that are known to work. They are sa
by _0w8t 5y ago
Go could have provided message queues with priorities Erlang style or something closer native solutions in Linux/Max/Windows that are known to work. They are safe, allows to avoid deadlocks just as channels and much more flexible.
And with mutex one can build those as necessary, even if interaction with channels is ugly.
- sriram_malhar 5y agoErlang doesn't have priorities natively, does it? As far as I am aware, there is a standard pattern to do it, like this: receive {high_p, Message} -> process_high(Message) after 0 -> receive {high_p, Message} -> process_high(Message); {low_p, Message} -> process_low(Message) end end The Go equivalent can be done with different channels for priorities and similarly nested selects, as I am sure you are aware.
- _0w8t 5y agoHm, is this pattern the best Erlang has and VM does not optimize it to avoid the need to lock the queue twice? If so then you are right double-select is equivalent even if it is rather messier in Go then in Erlang with the need to provide 2 channels.
- ergl 5y agoErlang has selective receive, meaning it will go through all your receive branches in order, until one matches. With this code: receive {high_p, Message} -> process_high(Message); {low_p, Message} -> process_low(Message) end if the process has one high_p message and a low_p message, the high_p message will be processed first.
- dragonwriter 5y ago> Go could have provided message queues with priorities Erlang style Erlang doesn't have priorities; you can fake them with selective receive, but IIRC selective receive is considered a code smell and something that should generally be avoided or minimized. (You can also have a separate process act as a priority queue channel by, well, storing messages in an actual priority queue structure and sending from its head, and that's a little more robust.)