[erlang-questions] Regarding clearing gen_server state

[Edmond Begumisa]

Oh, sorry, I misread! I thought you wanted to unsubscribe on a  
crash/error. For the opposite; unsubscribing during ordinary termination  
(anything other than an error)...

terminate(normal, {P, I}) ->
   P ! {unsubscribe, I},
   ignore;
terminate(shutdown, {P, I}) ->
   P ! {unsubscribe, I},
   ignore;
terminate({shutdown,_}, {P, I}) ->
   P ! {unsubscribe, I},
   ignore;
terminate(_Crash, _) ->
   ignore.

- Edmond -

On Mon, 21 Feb 2011 01:48:12 +1100, Edward Wang <yujiangw@REDACTED> wrote:

> 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/
>>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/