[erlang-questions] ETS tables and pubsub

akonsu akonsu@REDACTED
Wed Nov 13 18:47:43 CET 2013


thanks. yes, these links are what got me started. it looks like for my
problem, gproc (or maybe gp2) is a good solution.


2013/11/13 Mark DeVilliers <Mark.deVilliers@REDACTED>

>  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> 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
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> 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/df416b02/attachment.htm>


More information about the erlang-questions mailing list