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?
