[erlang-questions] Complex gproc queries

[Pablo Platt]

I should have said that Roster is a list with the contact list IDs
Roster = [id1, id2, id3...]
each user have a different list.
I need to send a message to all the the users in the list that are online.

Thanks





________________________________
From: Ulf Wiger <ulf.wiger@REDACTED>
To: Pablo Platt <pablo.platt@REDACTED>
Cc: erlang-questions@REDACTED
Sent: Fri, April 2, 2010 7:37:25 PM
Subject: Re: [erlang-questions] Complex gproc queries

Pablo Platt wrote:
> Hi,
> 
> I'm building a simple chat server and using gproc to keep track of online users and the process for each user session.
> 
> Basically, each online user has a process that register a unique session id and non unique user id (same user can have several clients):
> gproc:add_local_name(SessionId)
> gproc:add_local_property(UserId, undefined)
> 
> When a user change his presence(online/busy/offline) I need to inform all the users on his roster.
> After I retrieved the roster from the db, how can I select all the processes with UserId that is a part of the roster?
> Rusty Klupaus's blog about gproc note that gproc:select support QLC but I don't understand how to do it.
> http://rklophaus.com/blog/2009/9/16/gproc-erlang-global-process-registry.html
> 
> Thanks

Not sure if you need any complex queries for that.
If all members of a roster have a property {p,l,Roster},
then all it should take is:

gproc:send({p,l,Roster}, Msg)

If you want to e.g. exclude the sender, you could use:

[P ! Msg || P <- gproc:lookup_pids({p,l,Roster}) -- [self()]]

Disclaimer: When verifying this, I found that gproc:send/2 was
broken for properties. I fixed it in the last commit, 1 minute ago.

The commit also changes anther bug: aggregated counters had to
have an integer value when created. This doesn't make sense, since
the value is derived; therefore the only sensible value is 'undefined',
which is what you get if you call gproc:reg({a,l,AggrCounter}).

Unfortunately, the commit broke the QuickCheck suite... I had forgot
that I started writing a test for gproc:await/1 at the SF Erlang
factory, didn't finish it. Oh well, if anyone is really hurt by
this condition, let me know. (Hans, I haven't merged your changes
yet).

BR,
Ulf W
-- Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
http://www.erlang-solutions.com
---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com