<div dir="ltr"><p class="MsoNormal">In many high-demand systems control flow and data use separate (often physically separate) communication channels so that even in case of overflow in data channel system is still responsive for control type of messages. Erlang does not have such built-in mechanism. I propose that Erlang messages have 2 priorities, higher priority message always takes precedence over lower priority message. I propose that higher priority messages are called signals.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">== Problems it addresses ==<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">1) if process is processing loads of messages there is no efficient and elegant way of controlling this process as control messages would queue up behind "data" messages. Selective receive is not the answer as it cost grows with the size of the queue.<u></u><u></u></p><p class="MsoNormal">2) gen_server:call is blocking which is perfectly fine, selective receive that is happening behind the scenes is not.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">== Sending ==<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I propose following syntax for sending signals<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Pid ! Message   % to send normal priority message<u></u><u></u></p><p class="MsoNormal">Pid !! Signal   % to send high priority, control messages<u></u><u></u></p><p class="MsoNormal">erlang:signal(Pid, Signal).<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">== Receiving ==<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Receiving signal would be no different to receiving normal message. Signals should appear as if they are added to the head of the Inbox (unless of course other signals are already present)<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">== Clustering ==<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">For this mechanism to work as expected across the network signals should have their dedicated TCP connections. Whether to set up dedicated signaling TCP connections might be specified by argument to erl VM in the same way as cookie or name is.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">== Backward compatibility ==<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Erlang VM with that new feature will be backward compatible at least at Erlang source level.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">== Applications ==<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">1) Any message that is send to a process that is expecting that message doing selective receive should be send as signal. All gen_server:call responses should be signals so selective receive can be avoided<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">2) Any operational type of messages that are sent to control behaviour of the process should be sent as signals. For processes handling large number of messages it is not possible to control process quickly enough - control message might arrive way to late.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">== Anti-abuse ===<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">To lower the risk of abusing signals following measures might be considered:<u></u><u></u></p><p class="MsoNormal">1) requiring processes to acquire "special permission" to send signals, without it signals would be just simple messages<u></u><u></u></p><p class="MsoNormal">2) making sending signal blocking operation that is semantically very different to asynchronous message sending<u></u><u></u></p><p class="MsoNormal">3) limiting the type of messages that could be sent as signals (e.g. atoms only)<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">== Implementation ==<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I do not know much about Erlang VM internals but 2 possible solutions come to my mind:<u></u><u></u></p><p class="MsoNormal">1) Separate inboxes: one for messsages, one for signals.<u></u><u></u></p><p class="MsoNormal">2) Double-headed inbox queue, one head for messages, one for signals.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Both solutions would probably increase the cost of spawning process and its memory footprint so it might be also worth considering following:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">1) lazy-initialization (e.g. on the receipt of the first signal).<u></u><u></u></p><p class="MsoNormal">2) setting up separate inbox for signals only if it is explicitly requested<u></u><u></u></p><p class="MsoNormal">3) optimizing with the assumption that signals would be rare events<u></u><u></u></p><p class="MsoNormal">4) making sending signals blocking operation so most of the cost is on sender's side.<u></u><u></u></p><p class="MsoNormal"><u></u> </p></div>