[erlang-questions] ETS tables and pubsub

Mark DeVilliers Mark.deVilliers@REDACTED
Wed Nov 13 16:01:40 CET 2013


Does this help - http://steve.vinoski.net/blog/2011/03/23/dont-lose-your-ets-tables/ and http://steve.vinoski.net/blog/2013/05/08/implementation-of-dont-lose-your-ets-tables/

Mark

From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Barco You
Sent: 13 November 2013 05:20
To: akonsu
Cc: erlang-questions
Subject: Re: [erlang-questions] ETS tables and pubsub

Why don't you use gproc?

On Wed, Nov 13, 2013 at 2:38 AM, akonsu <akonsu@REDACTED<mailto:akonsu@REDACTED>> wrote:
I have a pubsub system which has a single publisher process that maintains all its subscriber processes' Pid's in an ETS table.

The publisher monitors its subscribers and when the publisher receives DOWN message, it removes the subscriber Pid from the table.

The table entries are tuples of the form {MonitorRef, SubscriberPid}, and the MonitorRef is used as the key.

Now I would like to make sure that if the publisher dies, and gets restarted by its supervisor, the subscriber table is preserved. So I created a process that creates the ETS table, sets the table's heir to self(), and then gives away the table to the publisher.

The problem is that I do not know how to handle transfer of the table from the heir to the publisher:

when publisher receives the table, the table contains a list of tuples {MonitorRef, SubscriberPid}, but the MonitorRefs were created by the previous publisher instance, so when the new publisher receives ETS_TRANSFER it needs to monitor all these SubscriberPids again.

what is the best way to do it? Loop over all ETS entries, attach a monitor to each and reenter the new MonitorRefs into the table? This might be slow, no? Maybe my architecture can be improved? Any advice?

thanks
Konstantin

_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED<mailto:erlang-questions@REDACTED>
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131113/58f117e8/attachment.htm>


More information about the erlang-questions mailing list