Description of problem:
POSIX signal handling still not happening
Version-Release number of selected component (if applicable):
Easily seen in a MT program
Steps to Reproduce:
1.Call setitimer in one thread
2.Exit the thread
3.Process never gets the ALRMs
glibc, not tftp
You mean like:
sig (int signo)
ret = 1;
tf (void *arg)
struct itimerval it;
it.it_value.tv_sec = 1;
it.it_value.tv_usec = 0;
it.it_interval = it.it_value;
if (setitimer (ITIMER_REAL, &it, NULL))
puts ("setitimer failed");
signal (SIGALRM, sig);
if (pthread_create (&th, NULL, tf, NULL))
puts ("pthread_create failed");
Can you please file an interpretation request with the Austin group?
The standard is certainly not very clear whether the 3 listed timers
must be per-process or per-thread and how should be the timer expiration
signalled in a mt environment.
The standard certainly manages not to be very clear about it, true.
I have always taken it as unambiguous that itimers are per-process,
not per-thread, and feel confident that is the intended specification.
This is already on my list of known-wrong things in the Linux kernel.
Changing product and version.
On rechecking the standard, I think it is already unambiguous that the
timers are per-process. I don't think we need any clarification from
the standards body.
I consider this a known bug in Linux 2.6, where it persists.
I do intend to get it fixed there at some point, but when that can
happen depends totally on upstream acceptance. This is the kind of
behavior that we would be unlikely to make different in a future RHEL
kernel than whatever the future upstream kernel does. However, even
if it does change in the future it seems doubtful that we would change
system call semantics in this way in an RHEL3 update kernel.
As additional details to the problem as originally found, and our
We need system time independant, hires timers. Of course a call like
the Solaris gethrtime be used. But that is not there on Linux. Instead
we can also set up a high resolution kernel timer and get a signal
when it times out, aka, setitimer. Problem is, what if the thread
calling the setitimer exits / is cancelled before the timer goes off?
Due to this bug, the process to which the thread belonged to never
gets a signal delivered, since the timer itself (in Linux) is per
thread, and dies with the thread.
Can we have an update on when in 2.6 you are looking at fixing this?
I'm closing this old bug for RHEL3, which is not going to get a semantics change
like this. The upstream kernel has these changes as of 2.6.12rc2 and they
should be in the released 2.6.12 soon. They are not in RHEL4, which is based on
and it is unlikely that a change in semantics such as this will come into RHEL4
in an update. At any rate, this bug is for RHEL3 and RHEL3 certainly won't change.
RHEL5 will certainly have this fixed, and RHEL4 can be addressed in a separate
bug if there is a need for it to be changed there.