If the things you are pooling are gen_servers, gen_server_pool may work for you (<a href="https://github.com/joelpm/gen_server_pool">https://github.com/joelpm/gen_server_pool</a>). That's a slight modification on a version I've used in production to pool thrift and protobuff conns to back-ends. To start a pool you'd simply do gen_server_pool:startlink( ..., GenServerPoolArgs). instead of doing gen_server:start_link(...). You would use the returned PID in the same way. I haven't had time to test that version, though, so YMMV.<div>
<br></div><div>Joel<br><br><div class="gmail_quote">2011/8/4 Andrew Berman <span dir="ltr"><<a href="mailto:rexxe98@gmail.com">rexxe98@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Awesome!  This makes sense.  Thank you for the clarification on this.<br>
<br>
2011/8/4 Frédéric Trottier-Hébert <<a href="mailto:fred.hebert@erlang-solutions.com">fred.hebert@erlang-solutions.com</a>>:<br>
<div><div></div><div class="h5">> Technically, the OTP supervision tree is also used for application upgrades (appups & relups). When sending messages to do the broad reloading of code, the code in charge of that just traverses the VM's supervision trees asking the supervisors what kind of modules they have and whether they're workers and supervisors (that's why the child specs contain details about workers, supervisors, [Modules] (and dynamic sending special messages to figure out the same info).<br>

><br>
> If you want to use appups/relups, you have to use the OTP supervision trees otherwise you will have processes left behind to be purged rather than upgraded.<br>
><br>
> --<br>
> Fred Hébert<br>
> <a href="http://www.erlang-solutions.com" target="_blank">http://www.erlang-solutions.com</a><br>
><br>
><br>
><br>
> On 2011-08-04, at 13:39 PM, Hynek Vychodil wrote:<br>
><br>
>> Using OTP supervisor tree is intended only for control of restarting<br>
>> application parts. If you want anything else you have to use links or<br>
>> monitors unless you write your own supervisor which is not recommended<br>
>> way.<br>
>><br>
>> On Thu, Aug 4, 2011 at 6:35 PM, Andrew Berman <<a href="mailto:rexxe98@gmail.com">rexxe98@gmail.com</a>> wrote:<br>
>>> Thanks Tim.  So it looks like they are using erlang:monitor and<br>
>>> demonitor, so is that the best approach in an OTP application?  How<br>
>>> does it figure into the supervision tree?<br>
>>><br>
>>><br>
>>><br>
>>> On Thu, Aug 4, 2011 at 3:22 AM, Tim Watson <<a href="mailto:watson.timothy@gmail.com">watson.timothy@gmail.com</a>> wrote:<br>
>>>> Take a look at the sources for <a href="http://zotonic.com/" target="_blank">http://zotonic.com/</a> as they use a<br>
>>>> decent connection pool.<br>
>>>><br>
>>>> On 4 August 2011 08:01, Andrew Berman <<a href="mailto:rexxe98@gmail.com">rexxe98@gmail.com</a>> wrote:<br>
>>>>> I'm fairly new to Erlang and I am trying to write a process pool which<br>
>>>>> essentially is a connection pool to a database.  I have designed the<br>
>>>>> application like this:  The main pool gen_server has a queue of PIDs<br>
>>>>> of gen_fsm's.  Each gen_fsm calls spawn_links a 3rd party gen_server and carries<br>
>>>>> the state of the connection.  So the 3rd party gen_server and the<br>
>>>>> gen_fsm should always live and die together.  I currently have set it<br>
>>>>> up such that gen_fsm calls proc_lib:spawn_link() to start the 3rd<br>
>>>>> party gen_server, but I'm wondering how this factors into the<br>
>>>>> supervision tree.  I currently have two supervisors:<br>
>>>>><br>
>>>>> Sup1 -> one_for_all -> 2 children: pool gen_server and Sup2<br>
>>>>> Sup2 -> simple_one_for_one -> 1 child: gen_fsm<br>
>>>>><br>
>>>>> So my question is: is it ok to use spawn_link instead of somehow<br>
>>>>> trying to put the 3rd party gen_server into the supervision tree?  If<br>
>>>>> it should go into the supervision tree, how would I organize the tree<br>
>>>>> then such that the gen_fsm and 3rd party gen_server are reliant on<br>
>>>>> each other?<br>
>>>>><br>
>>>>> Thanks for any help!<br>
>>>>> _______________________________________________<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" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>>>>><br>
>>>><br>
>>> _______________________________________________<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" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> --Hynek (Pichi) Vychodil<br>
>><br>
>> Analyze your data in minutes. Share your insights instantly. Thrill<br>
>> your boss.  Be a data hero!<br>
>> Try GoodData now for free: <a href="http://www.gooddata.com" target="_blank">www.gooddata.com</a><br>
>> _______________________________________________<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" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
><br>
_______________________________________________<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" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>