search

uwiger / gproc

Extended process registry for Erlang
Apache License 2.0
1.07k stars 232 forks source link

Why does not gproc do `erlang:demonitor/1` when one do 'gproc:unreg/1`? #91

Open massn opened 9 years ago

massn commented 9 years ago

Hi,

Gproc applies erlang:monitor/1 to a process when one do gproc:reg/1, but it seems that the monitor will never demonitored unless the process is down. Should we care about those useless monitors?

I would appreciate hearing your opinion.

uwiger commented 9 years ago

Well, it's a tradeoff.

gproc uses at most one monitor per Pid+scope, and this is ensured by gproc_lib:ensure_monitor/2, which uses ets:insert_new/2 - thus very cheap. In order to know when to remove a monitor after unreg, I would either have to use reference counting, or use one monitor per registration. This would in its turn mean (potentially) lots of 'DOWN' messages to the gproc server once a process dies, as well as possibly significantly greater memory footprint in systems that really go to town with registrations.

My assumption has been that most users will register names and properties and let them stay until the process dies, but I guess a use case where lots of processes occasionally register and then unregister with gproc would find this sub-optimal.

massn commented 9 years ago

I can understand many people rarely use unreg, but I think storing Ref (Ref = erlang:monitor(process, Pid)) and demonitor it after unreg decrease 'DOWN' messages. Will it raise the efficiency without the tradeoff?

Perhaps, I do not catch your point of the tradeoff. Especially 'use reference counting'...