Inline, as well :) Matthias
On Mon, 14 Jan 2008, Brad Nicholes wrote: > [...] > > In addition, the host hash table and associated struct should probably be > moved from gmond to libganglia as well. > That way the API go get the hosts could be made external without having > to start exposing external APIs directly from gmond. I intend to move the hosts table then completely out of gmond and create a self-contained abtract variable in libganglia. That will allow gmond as well as module to access the current host set. Q: Do you think it needs to be MT-safe or can I get away with it for now without protection ? Essentially, this boils down to this question: are the module executed in separate threads or in gmond's thread context ? > >> Python modules don't have any way of calling back into gmond for > >> additional > > information. > >> The mmodule_struct is not exposed directly to a python module either so > >> the same trick of passing a common pointer through a structure won't > >> work. The only way to do it would be to add another parameter to the > >> handler call when mod_python calls into the python module. But this > >> seems kind of messy because 99% of the time for other python modules, > >> that parameter will complete unnecessary. > > > > You've mentioned above the one-way communication going from gmond to a > > Python module. How about we introduce another optional callback that > > takes as a parameter the host list, thus picking up your idea. Then > > whenver gmond updates the host list in mmodule_struct it calls this > > optional method on all python modules ? Of course, if we would some > > day end up with > 100 modules that might become a performance problem. > > However, the callbacks could be invoked asynchronously from a dedicated > > gmond thread. > > > > I would like this idea better if the optional callback could be made more > generic. > In other words, if there was a set of data that a python module could > get from gmond and the module could simply register for what it wanted. > Then the extra data could be added as optional parameters to the > metric_handler callback rather than an additional callback. I'll have > to think about this some more. I concur, this would be more flexible and yet stabilize the API. > > >> Bottomline is, I'm not sure > >> what a good solution is for this whole thing. How about a pointer to an array of pointers. One pointer would then point to the host list. We could extend this then in the future. > >> > >> > >> > Also, I think it would be useful if the DSO module could unload itself. > >> > As I understand all modules that are under > >> > /usr/lib/ganglia/python_modules/ are automatically loaded. However, if > >> > e.g. the IPMI module determines that it can't function because of missing > >> > or unfitting (wrong version) SW pieces, then it should unload itself. > >> > > >> > What say you ? > >> > > >> > >> I think that providing a python module with the ability to unload itself > >> is > > a great idea. > >> Basically the metric_init function would need to return some kind of > >> indications that it wants to be unloaded. Since the metric_init function > >> returns a list of dictionaries that contain the metric definitions that > >> the module provides, probably the best way to indicate that it wants to > >> be unloaded would be to return an empty list. If mod_python detects an > >> empty list, then it would just unload the module and continue on. I > >> could see this being useful by allowing the python module to detect if > >> any of the metrics that it provides have been referenced in the > >> configuration file. If not then just unload itself. > > > > I like this implementation. Do we need to allocate a NULL parameter set > > for modules that do not expose metrics and only implement a side effect ? > > Is this every conceivable ? > > > > Maybe, I haven't really thought about that. > I think we should define explicitly a NULL_METRIC entry. Matthias ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
