[erlang-questions] gproc scalability, shared ets, links and using terminate/2

[Joseph Norton]

I've been using a "goodbye" patch for the gproc application to help move some of the cleanup work to the client side and lessen the work of the centralized gproc server.

https://github.com/norton/gproc/commit/e2c4108c2ceae5d86ca78f9f1d5e5c6b45f7309a

Not (quite) sure if this is helpful to your use case or not.

- Joe N.

On Nov 9, 2011, at 11:00 PM, Max Lapshin wrote:

> On Wed, Nov 9, 2011 at 1:06 PM, Ulf Wiger
> <ulf.wiger@REDACTED> wrote:
>> 
>> It's true that link/1 has that advantage.
>> 
>> The disadvantage is that if the server crashes, and is linked to, say, 100K processes, the EXIT signal will be duplicated that many times, likely forcing an OOM crash.
>> 
> 
> I understand. But I don't have anything to do, except hoping that
> server will not crash, because with monitor in my situation system
> gets frozen under normal load.
> 
> And 100 K of messages is not a reason for OOM. Dumping these messages
> will be an OOM, error logger is the main reason to bring down VM.
> 
> 
> By the way, have you seen my previous claim about non-atomic process startup?
> Using supervisor  {error, {already_started,Pid}} feature is also not
> 100% unreliable because of race condition.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions