> If tcpconn is functioning normally after the initial startup, then that > basically answers the questions. It appears that at least on CentOS/RHEL5 > python is not yielding after calling start() and therefore not allowing the > threading module to call the threads run() method. The result is that by not > yielding, it is opening the window wider and allowing multiple calls to the > start() function. Adding a try...catch block around the start() call and > ignoring the exceptions will probably fix the problem. I would call this a > showstopper or a regression for the same reason that you stated. It is more > of a cosmetic annoyance which can be fixed. Nothing about this issue > actually prevents tcpconn from functioning normally. I can add the > try...catch block and check that code in or you can just tag and we fix it > next time. > >
Can you please try this on trunk, and we will aim to deliver the fix with 3.1.7. To get something tagged before Friday, I would prefer not to include any last minute changes unless we find an issue that is a serious regression or showstopper. ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
