Bug 250400 - Profiling signals generated by itimer only delivered to the main thread
Profiling signals generated by itimer only delivered to the main thread
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.5
All Linux
low Severity low
: ---
: ---
Assigned To: Roland McGrath
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-01 08:15 EDT by Neil Campbell
Modified: 2007-11-16 20:14 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-13 14:31:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test case which shows the behaviour described. (1.05 KB, text/x-c++)
2007-08-01 08:15 EDT, Neil Campbell
no flags Details

  None (edit)
Description Neil Campbell 2007-08-01 08:15:32 EDT
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.
Comment 1 Neil Campbell 2007-08-01 08:15:32 EDT
Created attachment 160407 [details]
Test case which shows the behaviour described.
Comment 2 Roland McGrath 2007-09-13 14:31:57 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.