>>> On 1/16/2008 at 12:46 PM, in message <[EMAIL PROTECTED]>, Matthias Blankenhaus <[EMAIL PROTECTED]> wrote: > 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 ? >
The answer is Yes and No. In other words, yes the modules are executed in the gmond's execution thread, however there is nothing preventing a module from spinning up its own threads and making calls back into libganglia. Obviously a C interface module is capable of spinning up threads of its own and we also made provisions for python modules to have the ability to spin up threads as well. Also, the return value from the API should be a pointer to either an apr_array, apr_table or apr_hash. This also means that the API will require an apr_pool as one of its parameters. >> >> 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. > In python speak, it would be a list of lists or a list of dictionaries. Mod_python would have to be modified to make the call into libganglia to get the extra data (in this case to get the hosts information). Then it would need to convert from an apr_array, apr_table or apr_hash (whatever the return value from the API call was) into a python list. The converted list would then need to be added as an element of the list object that would ultimately be passed to the python module. >> >> >> >> >> >> > 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. > I'm not sure what that would be or where it would be imported from. The metric modules are not required to import an special ganglia python stuff. So unless it is a standard data type with a value of NULL or an empty dictionary or list, I'm not sure what it would be. Brad ------------------------------------------------------------------------- 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
