<div dir="ltr"><div>Hi Garrett,</div><div><br></div><div>Thanks for playing. ;-)</div><div><br></div>In the case I have in mind, a given process may need to register multiple instances of a resource, where the key is basically {ServiceName, Route}. The resource count should keep track of instances of ServiceName, and especially trigger when the count reaches 0 (service no longer available).<div><br></div><div>While one could add an extra function that creates a resource, also updating a wildcarded resource count, this opens up for possible bugs where the wrong function is used to create a resource, throwing the count out of sync.</div><div><br></div><div>The proposed change was the most lightweight way I could think of to extend the 'rc' type, essentially adding one more layer of abstraction to it. But if there is another way, efficient and elegant, I'm wide open to suggestions.</div><div><br></div><div>BR,</div><div>Ulf W</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-12-01 19:11 GMT+01:00 Garrett Smith <span dir="ltr"><<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This doesn't feel right to me - it strikes me as edge case support<br>
that's impacting what's otherwise a very simple feature.<br>
<br>
If this is generally useful, would it make sense to implement it as a<br>
new function call, which made the additional update explicit?<br>
<div><div class="h5"><br>
On Thu, Dec 1, 2016 at 11:11 AM, Ulf Wiger <<a href="mailto:ulf@wiger.net">ulf@wiger.net</a>> wrote:<br>
> There's a new PR on Gproc, adding support for limited wildcard matching in<br>
> resource counters.<br>
><br>
> <a href="https://github.com/uwiger/gproc/pull/128" rel="noreferrer" target="_blank">https://github.com/uwiger/<wbr>gproc/pull/128</a><br>
><br>
> I don't know how many people use resource counters ('rc'), but thought I'd<br>
> ask.<br>
><br>
> The operation of registering (or unregistering) a resource now makes one<br>
> extra update_counter() protected by a try ... catch. My assumption is that<br>
> this extra overhead will be insignificant to just about all use cases, but<br>
> ... does anyone out there want to disagree?<br>
><br>
> Briefly, when registering a resource ('r') object, gproc would try to<br>
> perform an update_counter on the corresponding 'rc' object - an operation<br>
> that might fail if the 'rc' object doesn't exist. Now, if the name of the<br>
> resource is a tuple, it also tries to update an 'rc' object with the last<br>
> element of the name tuple replaced with '\\_'. This make it possible to<br>
> count resources whose names differ in only the last tuple element. For<br>
> non-tuple resource names, it works just like before.<br>
><br>
> BR,<br>
> Ulf W<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
><br>
</blockquote></div><br></div>