[erlang-questions] Regarding clearing gen_server state

[Edward Wang]

Neat, this is what I'm looking for. Thanks, Edmond. I presumed terminate/2
won't be called if it is a crash.

-Edward

On Sun, Feb 20, 2011 at 7:13 PM, Edmond Begumisa <
ebegumisa@REDACTED> wrote:

> No need to duplicate that information.
>
> * Noting that gen_server calls the terminate callback before it quits
> * Use this to determine if it's quiting abnormally
> * If so, send P the information it needs to unsubscribe
>
> i.e. From Q where I is the PnP info...
>
> init([P, I]) ->
>  process_flag(trap_exit, true),
>  {ok, {P, I}}.
> ..
> terminate(normal, _) ->
>  ignore;
> terminate(shutdown, _) ->
>  ignore;
> terminate({shutdown,_}, _) ->
>  ignore;
> terminate(_Crash, {P, I}) ->
>  P ! {unsubscribe, I},
>  ignore.
>
> - Edmond -
>
>
> On Sun, 20 Feb 2011 16:58:30 +1100, Edward Wang <yujiangw@REDACTED>
> wrote:
>
>  Oh, I think I get it figured out.
>>
>> Either I need a way to retrieve a gen_server's internal state when a
>> 'DOWN'
>> message is received. Is there any? Or, I should use ETS table to store
>> upnp
>> service information exclusively, which also eliminates duplication.
>>
>> -Ed
>>
>> On Sun, Feb 20, 2011 at 11:59 AM, Edward Wang <yujiangw@REDACTED> wrote:
>>
>>  Steve and Bernard,
>>>
>>> Thanks for your reply, that's helpful. I should have been more specific.
>>>
>>> I'm working on a UPnP implementation for Erlang recently. After a UPnP
>>> service in LAN being discovered, one gen_server Q is spawned to represent
>>> it. Q may tell UPnP service to subscribe to a HTTP callback Url. When
>>> terminating, unsubscribe it. If Q crashes, ideally, P should do the
>>> unsubscription.
>>>
>>> Only Q knows details about UPnP service. It holds that information in its
>>> state. There's also a ets table that has all Qs' pid. Other process can
>>> query the table and asks Q to do certain operation. I find such a design
>>> conceptually simple.
>>>
>>> Except for one problem. If Q crashes, all information about that UPnP
>>> service is gone. P can't do unsubscription for Q. So eventually, the ets
>>> table that has Qs' pid becomes to have all information about UPnP
>>> services.
>>> It is less elegant and, worse, duplication of the same data.
>>>
>>> Alternative solutions?
>>>
>>> Regards,
>>> Edward
>>> On Feb 20, 2011 7:28 AM, "Bernard Duggan" <bernie@REDACTED> wrote:
>>>
>>>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>