Re: Posix compliant CLOCK_PROCESS/THREAD_CPUTIME_ID V4

[Christoph Lameter]

On Wed, 29 Sep 2004, George Anzinger wrote:

> Christoph Lameter wrote:
> > George asked for a test program so I wrote one and debugged the patch.
> > The test program uses syscall to bypass glibc processing. I have been
> > working on a patch for glibc but that gets a bit complicated
> > because backwards compatibility has to be kept. Maybe tomorrow.
> > Found also that glibc allows the setting of these clocks so I also
> > implemented that and used it in the test program.  Setting these
> > clocks modifies stime and utime directly, which may not be such a good
> > idea. Do we really need to be able to set these clocks?
>
> Another way of doing this is to save these values in the task structure.  If
> null, use the direct value of stime, utime, if not, adjust by the saved value
> (i.e. saved value would represent time zero).

But this would require two additional int field in task_t just for that
rarely used functionality.

> Please, when sending patches, attach them.  This avoids problems with mailers,
> on both ends, messing with white space.  They still appear in line, at least in
> some mailers (mozilla in my case).

The custom on lkml, for Linus and Andrew is to send them inline. I also
prefer them inline. Will try to remember sending attachments when sending a
patch to you.

> As to the test program, what happens when you attempt to set up a timer on these
> clocks?  (No, I don't think it should work, but we DO want to properly error
> out.  And the test should verify that this happens.)  By the way, if you use the
> support package from sourceforge, you will find a lot of test harness stuff.

That is an interesting issue. If that would work correctly one could
trigger an signal if more than a certain amount of cputime is used.
It looks though that it will create an interrupt based on real time.

SuS says:

 Each implementation defines a set of clocks that can be used as timing
 bases for per-process timers. All implementations support a clock_id of
 CLOCK_REALTIME.

So restrict timer_create to CLOCK_REALTIME and CLOCK_MONOTONIC? Is it
necessary to be able to derive a timer from a timer derives from those
two?

something like the following (just inlined for the discussion ...)?

--- linux-2.6.9-rc2.orig/kernel/posix-timers.c  2004-09-28 20:29:28.000000000 -0700
+++ linux-2.6.9-rc2/kernel/posix-timers.c       2004-09-29 11:12:37.814713085 -0700
@@ -585,8 +585,8 @@
        sigevent_t event;
        int it_id_set = IT_ID_NOT_SET;

-       if ((unsigned) which_clock >= MAX_CLOCKS ||
-                               !posix_clocks[which_clock].res)
+       if ((unsigned) which_clock != CLOCK_REALTIME &&
+           (unsigned) which_clock != CLOCK_MONOTONIC)
                return -EINVAL;

        new_timer = alloc_posix_timer();

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/