Messages in this thread | | | Subject | Re: posix-cpu-timers revamp | From | Frank Mayhar <> | Date | Mon, 24 Mar 2008 15:43:37 -0700 |
| |
On Mon, 2008-03-24 at 10:34 -0700, Frank Mayhar wrote: > On Sat, 2008-03-22 at 14:58 -0700, Roland McGrath wrote: > > The analysis above is correct but your conclusion here is wrong. > > The current value of an itimer is a user feature, not just a piece > > of internal bookkeeping. > > After looking at the code again, I now understand what you're talking > about. You overloaded it_*_expires to support both the POSIX interval > timers and RLIMIT_CPU. So the way I have things, setting one can stomp > the other. > > > Your code causes any timer_settime or timer_delete call on a process > > CPU timer or any setrlimit call on RLIMIT_CPU to suddenly change the > > itimer setting just as if the user had made some setitimer call that > > was never made or intended. That's wrong. > > Right, because the original effect was to only set the it_*_expires on > each individual task struct, leaving the one in the signal struct alone. > > Might it be cleaner to handle the RLIMIT_CPU stuff separately, rather > than rolling it into the itimer handling?
Okay, my proposed fix for this is to introduce a new field in signal_struct, rlim_expires, a cputime_t. Everywhere that the RLIMIT_CPU code formerly set it_prof_expires it will now set rlim_expires and in run_posix_cpu_timers() I'll check it against the thread group prof_time.
I believe that that will solve the problem, if I understand this correctly. If I don't, I trust that you will set me straight. :-) -- Frank Mayhar <fmayhar@google.com> Google, Inc.
| |