[erlang-questions] [clarify] Limits and overhead of monitors

[Hynek Vychodil]

No, no, your question was generally correct. It depend how monitor is
implemented. Sure that tree organisation of controllers and partitioning is
better solution for complexity. But how monitors work is good question
anyway. I think it is one process per node with ets and linked to monitored
processes, but I'm not sure. So anyway in your example it will be
9,999,900,000 records or 100,000 records with 99,999 list items each. If I
remember there is timers described same way in this email list and I guess
monitors can be implemented similar.

On Sun, Jun 8, 2008 at 6:15 AM, Jay Nelson <jay@REDACTED> wrote:

> > Do you really mean that each process would monitor the other 99,999
> > processes?  That would be 9,999,900,000 monitor relationships, so
> > at the
> > very least you've gotta have a lot of memory on those systems.
>
> I got carried away as I was writing the email and added this without
> thinking.
> No only that, but if one process goes down I will get 99,999 messages.
>
> I think I need to come up with a partitioning scheme or a hierarchy of
> processes which have a single notifier watching them so that only one
> 'DOWN' message is signalled and then I can cascade it as needed.
>
> So, I'm back to my original question of how many monitors can a single
> process hold.  I'll post the results of any benchmarking I do.
>
> jay
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



-- 
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080608/3e3ee412/attachment.htm>