[erlang-questions] wildcarded resource counters in Gproc

[Garrett Smith]

And another tack - is there a path here to a generalized interface for
alternative schemes? E.g. passing along a function to do some work on
the table? Maybe not for the faint of heart, but this would reduce the
temptation to modify the interface for these case.

On Thu, Dec 1, 2016 at 12:11 PM, Garrett Smith <g@REDACTED> wrote:
> This doesn't feel right to me - it strikes me as edge case support
> that's impacting what's otherwise a very simple feature.
>
> If this is generally useful, would it make sense to implement it as a
> new function call, which made the additional update explicit?
>
> On Thu, Dec 1, 2016 at 11:11 AM, Ulf Wiger <ulf@REDACTED> wrote:
>> There's a new PR on Gproc, adding support for limited wildcard matching in
>> resource counters.
>>
>> https://github.com/uwiger/gproc/pull/128
>>
>> I don't know how many people use resource counters ('rc'), but thought I'd
>> ask.
>>
>> The operation of registering (or unregistering) a resource now makes one
>> extra update_counter() protected by a try ... catch. My assumption is that
>> this extra overhead will be insignificant to just about all use cases, but
>> ... does anyone out there want to disagree?
>>
>> Briefly, when registering a resource ('r') object, gproc would try to
>> perform an update_counter on the corresponding 'rc' object - an operation
>> that might fail if the 'rc' object doesn't exist. Now, if the name of the
>> resource is a tuple, it also tries to update an 'rc' object with the last
>> element of the name tuple replaced with '\\_'. This make it possible to
>> count resources whose names differ in only the last tuple element. For
>> non-tuple resource names, it works just like before.
>>
>> BR,
>> Ulf W
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>