[erlang-questions] Regarding clearing gen_server state

Edmond Begumisa ebegumisa@REDACTED
Sun Feb 20 12:13:44 CET 2011


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/


More information about the erlang-questions mailing list