> >I would suggest: > > > > * Routines for acquiring basic information about running > processes > > such as memory usage, CPU usage, etc. Should work for > processes > > that were _not_ started via apr_proc_create(). Should allow > > enumeration of all processes on system (subject to > user permissions). > > > >But that's just me, and probably no one else cares. ;) > > No, that would be most cool. Care to offer a patch?
Maybe. I'm almost to the point of _really wanting_ this stuff for gross kinds of performance tuning. So perhaps I'll take a whack at it in the forseeable future. * A couple of issues stand out in my mind (having thought about this before): First, the kinds of data available about a process differ from one machine to another. Some of them are similar, so there's probably a way to generate a series of macros like the APR_FINFO_ macros that would target the least common denominator. But there will be a lot of OS-specific data that isn't covered, and some of the mappings may not be 100% equivalent. Second, in order to handle _all_ processes, this should probably _not_ be glued onto apr_proc_t. It might be possible to have apr_proc_from_pid() or some such, but then a bunch of apr_proc_*() routines won't apply because it's a 'foreign' process and things will get messy. It should, however, be possible to ask for process information about an apr_proc_t via something like apr_proc_pinfo(), just for completeness. Third, there is the need to iterate over the process list. So there is a dichotomy, a little like that between directory and file. There is an apr_dir_t and a series of functions to iterate over a directory and within the directory there are files, represented by apr_file_t, which have their own information. So I would probably generate an apr_ptable_t object that would have open, close, rewind and so forth and then read apr_pinfo_t objects from there. Or something vaguely like that. Fourth, there is the question of producing a similar interface for threads. In general it isn't possible to get the same type of information about threads, but there might be some use in producing a vaguely similar interface for apr_thread_t objects defined in the current application. It might be possible to produce total memory pool size and/or current locks or some such. But I'm way sceptical as to the feasibility and usability of this extension. * Usage cases: The goal of the interface, would be the ability to construct tools like ps and (partially) top. For me, the tool that I always want and never seem to have, is a persistent, periodic ps that logs info about my applications to a file or database so that I can go back later and review how well they're behaving. I would like to be able to put code into some persistent processes to measure how big or slow they're getting so that they know something is wrong (self diagnosis) and can gracefully suicide or whatever. * * * All of which is just off the top of my head and subject to better ideas. mma
