On Wed, 2007-04-25 at 08:17 -0600, Brad Nicholes wrote: > >>> On 4/24/2007 at 7:23 PM, in message > <[EMAIL PROTECTED]>, "Nick Galbreath" > <[EMAIL PROTECTED]> wrote: > > I'm not an official developer in ganglia, but I think it's great. > > > > Also note that in monitor-core/srclib/inetaddr.c contains a mutex-protected > > gethostbyname to be thread safe (which cleverly avoids the nightmare that is > > gethostbyname_r). That can probably be replaced with the one in > > apr_network_io.h in 'apr_sockaddr_info' Hmmm looking at inetaddr.c, a good > > bit of it could probably be replaced with apr code. > > > > If you need an assistance, let me know.
we always need assistance. that's the nature of open source projects. :) let us know how we can help you get started... > > > > --nickg > > > > Absolutely, I think that there are several things that should be replaced. > APR 1.2 introduces a set of multicast APIs as well that should probably > replace the multicasting functions in apr_net.c. i agree we should move to newer versions of APR. funny thing is that i submitted our mcast code to the apache group to help get them started adding mcast to APR. i would love it if we remove all the temporary hacks i stuck in there and used pristine APR instead. > There is also a function called apr_sockaddr_ip_buffer_get() in apr_net.c > that is a rewrite of apr_sockaddr_ip_get(). I understand the purpose for the > rewrite which is to avoid memory pool allocations that can't be freed, but > this function is calling a private APR function which is a little bothersome. > exactly right. agreed we shouldn't be calling any private apr functions. > The way this function is being called should probably be reworked to avoid > calling private APR functions and allow the memory pool allocations to be > cleaned up. I would suggest doing something like Apache where each > "transaction" (ie. processing metrics, handling an interactive request, etc.) > be given a transaction pool that is cleaned up once the transaction is > complete. Anyway, I am close to having the static dependancy removed and > once I get that committed into trunk, you cou > ld probably start creating the patches. thanks for all your time and effort, brad... it's very appreciated! -matt
