stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Black <>
Subject Re: [patch] Child process stats in exec utility (unix)
Date Thu, 14 Sep 2006 15:58:46 GMT
Greetings all

Attached is the revised version of this patch, now that the display 
subsystem has been implemented.

--Andrew Black

	* display.h (unistd.h) [!_WIN32 && !_WIN64]: Include.
	  (sys/time.h) [_XOPEN_UNIX]: Include.
	  (rw_time_t, rw_suseconds_t, struct rw_timeval) [!_XOPEN_UNIX]: Define 
placeholder structures.
	  (rw_timeval): Define abstraction typedef.
	  (struct target_status): Add run, user, sys elements.
	* display.cpp (unistd.h) [!_WIN32 && !_WIN64]: Include.
	  CHILD_STATS [_XOPEN_UNIX]: Define convenience macro.
	  print_header_plain: Alter output if CHILD_STATS is defined.
	  print_target_plain: Partition output column printing by section, add 
timing output if CHILD_STATS is defined.
	* exec.h (exec_file): Alter signature to accept target_status rather 
than char**.
	* exec.cpp (display.h): Include.
	  (calculate_usage) [_XOPEN_UNIX]: Define function to populate user and 
sys fields of provided target_status struct.
	  (exec_file): Alter to accept target_status rather than char**,  use 
argv element in place of old char** argument.
	  (exec_file) [!_WIN32 && !_WIN64 && _XOPEN_UNIX]: call calculate_usage 
after wait_for_child.
	* runall.cpp (run_target): Pass target_status struct rather than  argv 

Andrew Black wrote:
> Martin Sebor wrote:
>> Andrew Black wrote:
>> [...]
>>> It appears to me that a partial rewrite is necessary to split the 
>>> result display into its own subsystem.  This rewrite would accomplish 
>>> a couple things.  First, it should allow the addition of new columns 
>>> to the output in a simpler manner.  Second, it should allow for the 
>>> output to be formatted for for targets other than plain text 
>>> terminals.  Both of these changes would likely be considered 
>>> beneficial, but will require a separate patch.
>> Yes, I also think that will be necessary. Should I assume that
>> you don't expect this patch to be committed and plan to post
>> a more complete solution in its place? (One that also deals
>> with the Windows side of things?)
>> Martin
> I think that would be an accurate enough analysis of the situation.  My 
> (rough) plan is to create the display subsystem in one patch, then 
> return to this task once that patch has been completed and use that new 
> subsystem to display the additional statistics in a follow-up patch.
> --Andrew Black

View raw message