On Fri, Aug 16, 2013 at 12:23 AM, Ted Unangst <t...@tedunangst.com> wrote:
> On Thu, Aug 15, 2013 at 23:39, Philip Guenther wrote: > > Making ITIMER_PROF per-thread like that matches neither what other OS's > do > > nor POSIX. jsing@ pinged about this last week and my comment then was > > that this seems like a bug in signal delivery, not in the triggering of > > the profile timer: when SIGPROF is delivered, it should go to the current > > thread if it's a possible candidate. Indeed, that should always be true: > > picking some other thread delays delivery, breaks profiling, and violates > > the requirements on kill(2). > > Actually, here's my concern. There's only one timeout for the process. > What happens when two threads are running on two CPUs? Is there a > guarantee that cpu0 will both set and execute the timeout before cpu1 > sets it, or is there a race where cpu1 will fail to send the signal to > its thread because cpu0 has already processed the timeout? > You get one signal, which is correct: the criteria is that the process is supposed to be sent one signal after the process, totaling across threads, consumes it_value of CPU-time, and then another every time that total accumulates another it_interval again. When your process with two threads has its total crossover while two threads are running, it only crossed *once*, not twice, so it should only get one signal. (Well, if it_interval is small enough, smaller than a tick, then I suppose it's possible for the total to "cross twice" and generate two signals, but I don't think that's what you had in mind...) Philip Guenther
