[erlang-questions] Programming question

[Richard Carlsson]

Sean Hinde wrote:
> On 25 Jan 2007, at 08:23, Mats Cronqvist wrote:
>> try
>>    Res = gen_server:call(PidA, {op, stuff}),
>>    S1 = process(Res, S),
>>    loopB(PidA, S1)
>> catch
>>    C:R ->
>>      case is_process_alive(PidA) of
>>        true -> loopB(PidA,dosomething({C,R},S));
>>        false -> exit({C,R})
>>      end
>> end
> 
> This would work, but my is it ugly - how is anyone supposed to  
> remember to do that every time they want to be sure that the called  
> process has gone down (as opposed to any other reason for the call to  
> thrown an exception).
> 
> The problem as I see it is that the calling process only sometimes  
> get its 'EXIT' message - it depends on context.

If you have a library that uses the RPC model, as in the case of
'gen_server:call(...)', it is probably a bad idea to try to solve the
problems with RPC that have been known for ages, such as "what do I do
if the server goes down", by adding some ad-hoc handling code to every
remote call. (It can and will be screwed up anyway.) I think that the
interface should be used as it was intended (treating exceptions due to
server-down as any other exception out from the call), and that
additional supervision should be placed somewhere else, outside the
main program logic.

Sean is basically right here: he _ought_ to be able to use normal
links for this purpose (after all, links are the central built-in
"additional supervision" method in Erlang), regardless of whether
the implementation of gen_server:call() does things with links and
trapping of signals: that stuff should have been made transparent to
the user, but is obviously not. (One problem is that there can only
be a single link between two processes, so gen_server can't know
whether or not it should re-issue the caught signal to the caller.)

If this aspect of gen_server (and similar library functions) cannot
be fixed, e.g. by using monitors instead of links, then at a minimum it
should be documented that the functions will steal exit signals if you
try to link directly to the server.

Meanwhile, the fix I suggested previously should work fine: use an
intermediate process, whose signals the gen_server library does not
interfere with.

	/Richard