In article <20070116171850.5305f74f@localhost.localdomain>,
=?ISO-8859-15?B?TnXxbw==?= I.G <nuno.iglesias@gmail.comwrote:
Quote:
>El 16 Jan 2007 05:31:49 -0800
Quote:
>And then maybe I can redefine my question.
>What i need is to lauch some small programs, from the application , and
>try to keep informed about the execution. The programs does not have any
>relation between them and I can't access to it's source. What I mean is
>that I only have the binaries, the paremeters it need , and the output
>I must wait for.
>Usefull information should be the "Execution time", "memory consumed",
>, "state of execution", and "exit signal" (if more information
>can be collected .... :) ).
>And this porgram must run in more than one platform (included diferent
>OS).
The C standard itself doesn't admit that more than one process
might exist. The closest it comes is the system() function,
which the standard says has "implimentation defined" behaviour
(with the sole exception that there is a portable way to check
to see if the implimentation provides a command interpreter at all.)
So whatever you come up with will have to rely upon behaviours
not defined by the C language itself.
Is there a well-accepted fairly portable mechanism to do what
you want? Unfortunately not: you really will find that you will
have to use non-portable system-dependant calls.
The notion of "Execution time" gets fuzzy when you have a
system able to run multiple processes. Do you mean the time
that the process has actually been in control of the CPU? Do
you include the time that the operating system has been
executing something on behalf of the process (such as doing disk I/O) ?
Are you looking for the "clock time" since the process started,
even though some other process completely might have been hogging the CPU?
If the system has multiple processors or multiple cores, do you want
to count according to the number of active processors or cores devoted
to the process? And if the process isn't compiled to take advantage
of multiple cores and the extra cores are sitting idle because
the OS doesn't know how to schedule other processes on the extra
cores, then should the process be charged for the "opportunity cost"
of those cores sitting idle?
Similarily, "memory consumed" gets messy to characterize when you
take into account that the system only needs one copy in memory of
a shared library or DLL -- should each shared library or DLL be
counted in full against the memory consumed, or should the OS
periodically check how many processes happen to be using a particular
shared library or DLL right then, and "charge" each process for
an equal fraction of the memory occupied by the shared library or DLL?
"State of execution" can get complex when multiple threads or
multiple processors or multiple cores are involved.
The meaning of the various "Exit signal" is OS dependant -- signal #19
on Windows might be different than signal #19 on a Unix system; the
POSIX standard defines some standard signals, but also provides for
system-dependant signals, and those system-dependant signals *do*
vary between Unix-like OS's (and between the software versions
of any one Unix-like OS.) And you have to do special things in order
to get a POSIX environment on Windows; if I recall correctly
(and I'm not an expert on this), the POSIX subsystem is provided
with Windows XP Pro, but not provided with Windows XP.
There's an old joke that comes to mind for your situation:
Q: How do you get down off of the back of an elephant?
A: You don't: you get down off of the back of a duck; it's so much safer.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer
