(spawn_monitor/3)

[Ulf Wiger (ÄL2/EAB)]

I think one reason why this BIF hasn't been added is that 
you will get a DOWN message anyway, since calling 
erlang:monitor/2 on a non-existing process will do just that.

What do you gain, apart from one line of code, by making
it atomic? Granted, in the distributed case, you save some
network traffic.

/Uffe


-----Original Message-----
From: Sean Hinde [mailto:sean.hinde@REDACTED]
Sent: Monday, September 01, 2003 14:18
To: Erlang Questions
Subject: 


Hi,

There was in interesting interchange between Mike Williams and Joe 
Armstrong at the Erlang workshop on Friday about whether it was a 
mistake to make link/1 bidirectional or not. The conclusion was that 
both monitor and link were needed and that both are now provided with 
the addition of the monitor/2 bif.

Maybe it is time to finish the job and add the atomic spawn_monitor/3 
bif, which would prevent spawned processes killing the spawner (by 
sending {'DOWN' etc instead of {'EXIT' etc)

The number of times I have made a process trap exits and then keep an 
ets table of all known spawned worker processes just so that I can 
respond correctly to 'EXIT' messages from elsewhere is getting quite 
large, and a spawn_monitor bif would solve this very elegantly, apart 
from the other advantages.

R10 maybe?

Sean