Re: [boost] [system][timer] CPU timer first draft

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-06-25 17:44:39

Beman Dawes wrote:
> Jeff Garland wrote:
>> Beman Dawes wrote:
>
>> 2) get_process_times compile fails on Linux -- fairly obvious issue
>> here...I'm guessing you are testing on Windows :-)
> 
> Fixed. Vault .zip updated.
 >
> Yes, I was testing mostly on Windows. I tested on a Mac, and then forgot
> to retest after making some changes. It is working now on my Mac, but I
> don't have a running Linux system to test on.

I've posted a couple other changes in a new thread.

>> 3) I see some major overlap in your plans with Boost.Process.  You
>> are providing what amounts to a a simplified form of what I what
 >
>...snip details...
 >
> The interface for my example is one line of code:
> 
>    boost::system::cpu_time_reporter tr;
> 
> So while it might be implemented using Julio's process design, 
> cpu_time_reporter provides a completely packaged solution. Unless I 
> missed something (always possible!), I don't see process as providing 
> the same thing.

No it doesn't.  Are you saying the process_exec isn't going to be part of the 
system api?  That's the part the overlaps..

>> 4) Eating exceptions:
>>
>> I don't like this code.  I've been burned a few times by code that
>> does eats exceptions....
> 
> Throwing exceptions from destructors is usually considered a no-no. Note 
> that it is possible to use explicit calls to stop() etc., and detect 
> that an error occurred.
> 
> I guess someone could make a case that exceptions should be thrown 
> except in the destructor. I'll have to think about that.

Well, you're assuming that report will be called in a destructor.  If it isn't 
and some sort of exception is thrown then the application can't handle it 
because you've eaten it.  You could always have 2 versions:

     void cpu_time_reporter::report_no_exceptions() throws()
     void cpu_time_reporter::report()

>>> My plan is to submit the CPU timer stuff as part of a Boost.System
>>>  library, which packages small operating system dependent
>>> components together for convenience.
>> For the moment, I mostly see things that overlap other current
>> library efforts -- error codes excepted. That said, I really applaud
>> the effort.  In my view, Boost has being a piecemeal design OS api
>> portability -- as an example, we have 3 libraries that retrieve clock
>> time values from the system clock (thread, date-time, timer).
> 
> timer should be retired. threads should use date-time facilities. If 
> cpu_timer is better implemented by calling date-time or process, that is 
> OK with me, but I really like the simple cpu_timer and cpu_time_reporter 
> interfaces. A user should not have to master a complex library just to 
> write what amounts to one line of code.

I guess I should have made it clear that I like the cpu timer interface -- 
it's certainly valuable.  And I totally agree that we want simple things to be 
simple.  I'm mostly commenting on the broader purpose of System and what 
should be contained in it.  See below for more...

> Well, the error encapsulation really doesn't fit in any other single 
> library, so at that point the camel's nose is under the tent and so we 
> might as well acknowledge "system" as a small library and see what else 
> fits into it, I think.

Yep.  Again my thought is that it would be the collector for an OS portability 
layer.  So you might have something like:

   system/time.hpp
   system/process.hpp
   system/thread.hpp
   system/file.hpp
   system/posix_impl/time.hpp
   system/win32_impl/time.hpp
   ....

Of course, that make cpu timer somewhat questionable as an element of the 
system library -- it would need to be an add-on.

>> By returning a microseconds from functions like wall() the user can
>> use the date-time streaming operators directly including the output
>> formatting strings associated with time duration.  I believe this
>> would also eliminate the the double-based precision issues in the I/O
>> code.
> 
> That sounds like an improved way to implement cpu_time_reporter, and 
> offers other user benefits too, I would guess.

I think so.

>>  One problem I see is that date-time doesn't have an easy way
>> to do set-precision on i/o...something it probably needs.
> 
> My guess is that control over precision is something users really will want.

It hasn't come up yet, but I've been expecting it to....

Jeff