Description of problem: Profiling signals generated by itimer are not delivered to threads other than the main thread. Version-Release number of selected component (if applicable): RHEL4.5, kernel 2.6.9-55.ELsmp. Tested on i386 and ppc64 platforms. Also occurs in RHEL4.4. How reproducible: Easily. Steps to Reproduce: 1. Compile attached test case: g++ setitimer.cc -o setitimer -lpthread 2. Run the test case: ./setitimer 3. Observe lack of profiling signals delivered to child thread. Actual results: No profiling signals are sent to the newly created thread. The new thread is also unable to get the itimer settings. $ ./setitimer Main thread is 10331 itval: 0, 0, 0, 0 $ Expected results: The new thread, which is using CPU time, should receive profiling signals, eg: $ ./setitimer itval: 0, 4000, 0, 8000 4958: signal received 4958: signal received 4958: signal received ... $ Additional info: I've tried the test case on more recent kernel versions (2.6.16, 2.6.20) and it works as expected, ie all executing threads receive timer signals.
Created attachment 160407 [details] Test case which shows the behaviour described.
These are the expected semantics in RHEL4, setitimer et al are per-thread. This is not the POSIX semantics, but that is how Linux always behaved up to that time. The semantics of setitimer et al have changed in later kernels to conform to POSIX, and RHEL5 does behave correctly in this regard. The semantics of RHEL4 and older systems will not change in update versions.