Higher order receieve anybody

Tony Rogvall <>
Tue Feb 24 15:11:46 CET 2004


On Tuesday, Feb 24, 2004, at 09:48 Europe/Stockholm, Ulf Wiger wrote:
>
> I would like to see the possibility to divide messages into
> two separate categories: administrative (such as suspend,
> resume, inspect, upgrade) and operative (whatever the program
> is _really_ supposed to do. And I would like to be able to keep
> them separated without messing up the programming semantics.

One idea (tested and implemented) is to use a primitive 
erlang:signal(Pid,Sig, Info) to send
a primitive form of messages.  For example message passing could be 
implemented as
erlang:signal(Pid, 'MESSAGE', Message). In Multi Pro Erlang we did the 
signal dispatcher in C code.
In retrospect we should have implemented a signal dispatcher / 
signal_handler in Erlang. This way
all signals (including messages) would be processed by Erlang code. 
Then one could implement
the link semantics and message reception etc in Erlang code!
The signal handler should be called in the context of the receiving 
process with some kind of
interrupt semantics (when it comes to receive).


-module(signal_handler).
-export([handle_signal/3]).

handle_signal(From, 'MESSAGE', Message) ->
	erlang:queue_message(Message);
handle_signal(From, 'LINK', _) ->
          erlang:add_link(From);
...
	

/Tony



> /Uffe
> -- 
> Ulf Wiger, Senior System Architect
> EAB/UPD/S
>
> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption, 
> interruption, unauthorized amendment, tampering and viruses, and we 
> only send and receive e-mails on the basis that we are not liable for 
> any such corruption, interception, amendment, tampering or viruses or 
> any consequences thereof.




More information about the erlang-questions mailing list