Re: Proc Info API

["William A. Rowe, Jr." <wr...@apache.org>]

At 02:19 PM 6/26/2003, Marc M. Adkins wrote:

>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.

No doubt.  It seems like internal ap_os_proc_info_foo() sorts of APIs could
be designed first, which would be used in the end by an apr_proc_info_foo()
API once we recognize the common denominators.

Perhaps the current apr_finfo_t::valid bit flag could be used to identify what
info was available (it won't be consistent due to process permissions, etc.)

>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.

However, it's impossible to thoroughly introspect processes on Win32 if
you aren't the creator or running as root, and that leaves us needing the
handle we created the process with.

'Foreign' processes aren't an issue, that's what apr_os_proc_() api's are
for, importing raw pids or handles.

>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.

Well, an apr_table would be fine.  But I would iterate the list of processes
(created by this process, by user, systemwide etc.)  I wouldn't want us
to waste the storage and time recovering all available info about all available 
processes :-)  Let the user call apr_proc_info_get() or whatever on each one
that interests them.

>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.

Agreed this is the best proof-of-concept.

>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.

Good ideas; I'd point you at providing the internal functions first by platform
so we start to get an idea of the scope of the common denominators and
what eventually should become the public interface.

Bill