[eeps] Signals

[Marcin Sokolowski]

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.

 == Problems it addresses ==

 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.

2) gen_server:call is blocking which is perfectly fine, selective receive
that is happening behind the scenes is not.

 == Sending ==

 I propose following syntax for sending signals

 Pid ! Message % to send normal priority message

Pid !! Signal % to send high priority, control messages

erlang:signal(Pid, Signal).

 == Receiving ==

 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)

 == Clustering ==

 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.

 == Backward compatibility ==

 Erlang VM with that new feature will be backward compatible at least at
Erlang source level.

 == Applications ==

 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

 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.

 == Anti-abuse ===

 To lower the risk of abusing signals following measures might be
considered:

1) requiring processes to acquire "special permission" to send signals,
without it signals would be just simple messages

2) making sending signal blocking operation that is semantically very
different to asynchronous message sending

3) limiting the type of messages that could be sent as signals (e.g. atoms
only)

 == Implementation ==

 I do not know much about Erlang VM internals but 2 possible solutions come
to my mind:

1) Separate inboxes: one for messsages, one for signals.

2) Double-headed inbox queue, one head for messages, one for signals.

 Both solutions would probably increase the cost of spawning process and
its memory footprint so it might be also worth considering following:

 1) lazy-initialization (e.g. on the receipt of the first signal).

2) setting up separate inbox for signals only if it is explicitly requested

3) optimizing with the assumption that signals would be rare events

4) making sending signals blocking operation so most of the cost is on
sender's side.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20140927/f6bb5c08/attachment.htm>