4 ms·
I guess erlang is an example of keeping your flow linear, albeit at the cost of searching through the incoming event queue and thus reordering of events.
by roeles 3y ago
I guess erlang is an example of keeping your flow linear, albeit at the cost of searching through the incoming event queue and thus reordering of events.
- iudqnolq 3y agoCan you clarify? I haven't seen people peek at messages without consuming them in Erlang. Even so I don't see how this gets you reordering.
- toast0 3y agoI'm not quite sure, but I think what they're getting at is that when you send a message and immediately wait for the reply, that's generally a selective receive: in the optimized case, it inspects all inbound messages from after you created your outbound message; in the non optimized case, it looks through the whole process mailbox before waiting for new messages. Either way, it's processing some inbound messages before others for a process that is getting messages for requests as well as responses. Personally, I have seen ocassional attempts to prioritize inbound queues, but it gets unwieldy quickly: you end up either reading nearly the whole mailbox on each iteration, or having to queue non-priority messages yourself, or do terrible things in erts code to add the ability to send to the front of a mailbox.
- roeles 3y agoAs far as I understand, the receive[1] call performs pattern matching on messages in the queue. If no match is found, the call blocks until any of the patterns match. If a match is found, the first match is returned. Since you perform this pattern matching, this means that messages may not be processed in the order they were received. [1] https://www.erlang.org/blog/message-passing/ https://www.erlang.org/blog/message-passing/