reg_or_update_shared_local_counter about gproc HOT 10 CLOSED

Thinking again, I see that my issue maybe solve having a reg_or_locate for shared counters. Is that possible?

from gproc.

How about this:

safe_incr(C, Incr) ->
    K = {c,l,C},
    try gproc:update_shared_counter(K, Incr)
    catch error:_ ->
             try gproc:reg_shared(K, Incr), Incr
             catch error:_ ->
                      gproc:update_shared_counter(K, Incr)
             end
    end.

from gproc.

A reg_or_locate_shared() feels a little bit weird when I try to get a feeling for the semantics. Possibly an ensure_shared_reg(Key, Value)?

from gproc.

The safe_incr can still fail, right? It would need an infinite try catch as the reg/unreg can happen between the try catch treatment. Or am I understanding something wrong?

The reg_or_locate_shared name would be based on existing functions reg_shared and reg_or_locate, but I agree that it's not really meaningful alone.

What about reg_or_locate support the shared atom as other functions do? And the ensure_shared_reg/2 would be an alias?

Do you think that's a good enhancement to gproc?

I advocate for this inclusion as it would be possible to keep shared counters without the trouble of building a safe critical session when creating/destroying shared counters.

from gproc.

And now thinking about the counter, it would be a better approach to reg_or_locate and update the counter if exists.

update_or_reg_shared_counter ?

from gproc.

I think the three catch levels should be enough:

1. Either the increment succeeds, or the counter isn't there
2. Either we succeed in creating the counter, or someone beat us to it
3. If 2 fails the counter should still be there; then we increment.

The last increment should not have a catch, since it should fail for most other cases.

I'm sure one can create a bizarre case where another process first creates, then deletes the counter...

I'll think about what a new API function should look like.

Ulf Wiger
http://ulf.wiger.net/

25 jul 2013 kl. 23:06 skrev Eduardo Gurgel [email protected]:

The safe_incr can still fail, right? It would need an infinite try catch as the reg/unreg can happen between the try catch treatment. Or am I understanding something wrong?

from gproc.

Ok, thank you Ulf. I will just explain my use case:

I have processes based on an associated id that when they spawn, they:

• Check if a shared counter with their id already exists
• If it exists increment
• Otherwise create one

If another process with the same associated id spawn, they do the same.

When they terminate, they decrement. If it reaches zero, destroy the shared counter.

The creation/destruction can happen during the steps described above.

Resuming it would be awesome to have:

• reg_or_update_shared_local_counter(...., InitialValue, UnregValue)

Where if the counter reaches the unregvalue, for example 0, -1, it becomes unregistered.

Maybe this is too crazy. Thank you again! 👍

from gproc.

Considering the fact that many already think that the gproc API is bloated, I think I'll pass on adding this function. ;-)

from gproc.

I agree @uwiger and I think this change (erlang/otp#362) will solve my problems (considering that gproc will use it also if it gets merged).

from gproc.

Indeed.

from gproc.