[erlang-questions] gproc

Ulf Wiger ulf.wiger@REDACTED
Sun Feb 13 08:54:11 CET 2011

On 12 Feb 2011, at 20:35, James Churchman wrote:

> haves as ets:first(Tab) for a given type of registration object.
> See http://www.erlang.org/doc/man/ets.html#first-1. The registry behaves as an ordered_set table.
> -------
> Why does it behave as an ordered set? does this have any advantages ? i see with select/123 you can pattern match but even in this case does it help much ? and does begin ordered strongly effect performance, especially as i am only ever using it as a (single) process registry? can you pick an unordered set if you don't need it?

Actually, gproc relies on the ordered_set semantics in several places, not least when cleaning up after process death. It is possible that one could slightly improve performance using bag semantics, but then, having ordered_set semantics allows users to register complex properties, and do efficient queries on them (by binding the first part of the key).

Performance of ordered_set is quite good; I did use initial tests with 100,000 registered processes, and was quite pleased with how it scaled.

> "Second" :
> I want to do a fairly common pattern of registering a process and using it, unless its already registered where i use the registered one
> so for a local registration : 
> gproc:reg({n, l,"ID"}).
> however on a second (and therefor "failing" ) registration it gives 
> exception error: bad argument: [{gproc,chk_reply,{reg,{n,l,ok2},undefined}},         {erl_eval,do_apply,5},     {shell,exprs,7},     {shell,eval_exprs,7},      {shell,eval_loop,3}]
> i can obviously catch this, but it would be nicer if it did the genserver style of returning {error , already_exists , PID / Value_Stored_At_That_Key}

Hmm, one way you could do this would be:

get_pid(Name, F) ->
   spawn(fun() ->

…or did you want a function similar to wait, where the calling process registers itself if there isn't already a process registered?

Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.

More information about the erlang-questions mailing list