[erlang-questions] ETS tables and pubsub

[akonsu]

Very informative. Thanks.

Having no experience with either gproc or pg2, I am trying to decide on
which one to use. So far I am only working with a single node, but still I
need to understand how things would work when I have to distribute them,
and what will have to be changed.

If I use pg2, then to broadcast a message I need to manually iterate over
the list returned from pg2::get_members. Is it a viable alternative to
gproc::send? I assume it creates a copy of each item. what if I have many
items?

Konstantin


2013/11/13 Christopher Meiklejohn <cmeiklejohn@REDACTED>

> On Wednesday, November 13, 2013 at 12:19 AM, Barco You wrote:
> > Why don't you use gproc?
>
> Last time I checked, gproc isn’t super reliable under failure conditions
> in global distribution mode.
>
> Garret and Ulf have discussed it on erlang-questions [1], section 10 of
> Ulf’s Erlang Workshop paper [2] covers quite a bit about it, and I’ve also
> written about it [3].
>
> [1] http://erlang.org/pipermail/erlang-questions/2012-July/067749.html
> [2] http://svn.ulf.wiger.net/gproc/doc/erlang07-wiger.pdf
> [3]
> http://christophermeiklejohn.com/erlang/2013/06/05/erlang-gproc-failure-semantics.html
>
> - Chris
>
> > 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
> >
> >
> > _______________________________________________
> > 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/6b14102a/attachment.htm>