It's more than a 'good fit' and it's almost exactly what I was looking at building myself.<br><br>Thank you!<br><br>-mox<br><br><div class="gmail_quote">On Sat, Apr 9, 2011 at 5:14 AM, Mihai Balea <span dir="ltr"><<a href="mailto:mihai@hates.ms">mihai@hates.ms</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5"><br>
On Apr 8, 2011, at 8:05 PM, Mike Oxford wrote:<br>
<br>
> I have a pool of resources, say 10k children(FSMs) each holding a resource.<br>
><br>
> If I want to remove a resource from the pool, of which they may be duplicates, I have two options.<br>
><br>
> 1)  Walk the list of children and tell each one "hey, if this is you, close up shop."<br>
> 2)  Maintain a dict/ETS of all resources, which has more run-time overhead and a higher likelyhood<br>
>      of "something happening."<br>
><br>
> If the supervisor dies, all resources are shut down as they're children, so having the supervisor maintain<br>
> the dict/ETS is an option.<br>
><br>
> Having another FSM outside the call-tree maintaining that status is an option but, in the case of that<br>
> FSM going down then all resources are "lost" and should be released....which minics the case of<br>
> a supervisor going down..<br>
><br>
> So...<br>
> Do I maintain state external to the supervisor or..<br>
> Have the supervisor maintain state or...<br>
> Just deal with the message-storm on resource removal?<br>
<br>
</div></div>Have you looked at proc / gproc?<br>
If your children can be identified by some sort of name or tag, then it might be a good fit for you.<br>
<font color="#888888"><br>
Mihai</font></blockquote></div><br>