[erlang-questions] Programming question

Sean Hinde sean.hinde@REDACTED
Wed Jan 24 16:12:54 CET 2007


Well, we do not use OTP supervisors. We have our own which implements  
something not dissimilar to the timed backoff restarts that someone  
asked for recently on the list.

It does not however support the *many supervisor strategies.

Sean

On 24 Jan 2007, at 14:22, Ulf Wiger ((TN/EAB)) wrote:

>
> Through the use of supervisors, you can either set up the
> processes under a one_for_all supervisor or a rest_for_one,
> where B is started after A. Then, if A dies, the supervisor
> will kill B.
>
> BR,
> Ulf W
>
>> -----Original Message-----
>> From: erlang-questions-bounces@REDACTED
>> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Sean Hinde
>> Sent: den 24 januari 2007 15:09
>> To: Mats Cronqvist (TN/EAB)
>> Cc: Erlang Questions
>> Subject: Re: [erlang-questions] Programming question
>>
>>
>> On 24 Jan 2007, at 13:42, Mats Cronqvist wrote:
>>
>>> Sean Hinde wrote:
>>>> Hi,
>>>>
>>>> A quick question for Erlang gurus out there.
>>>>
>>>> I have two processes A and B. B spends most of its life in
>> a series
>>>> of gen_server calls towards A:
>>>>
>>>> loopB(PidA, S) ->
>>>>       Res = gen_server:call(PidA, {op, stuff}),
>>>>       S1 = process(Res, S),
>>>>       loopB(PidA, S1).
>>>>
>>>> The question is how do I set things up so that if A dies B
>> is killed?
>>>
>>>
>>>   as a non-guru, i was thinking that happened automatically
>> as soon as
>>> you made the call?
>>>
>>> 1> is_process_alive(Pid).
>>> false
>>> 2> gen_server:call(Pid, {op, stuff}).
>>> ** exited: {noproc,{gen_server,call,[<0.14604.0>,{op,stuff}]}} **
>>
>> loopB spends most of its time waiting for a reply to the
>> call. The likelihood is that Process A will die during the
>> processing of the call, not while it is being "sent". In that
>> case the above will not happen. Question still stands :-)
>>
>> Sean
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>




More information about the erlang-questions mailing list