Description of problem: POSIX signal handling still not happening Version-Release number of selected component (if applicable): How reproducible: 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 Actual results: Expected results: Additional info:
glibc, not tftp
You mean like: #include <signal.h> #include <stdio.h> #include <time.h> #include <pthread.h> #include <sys/time.h> int ret; void sig (int signo) { ret = 1; } void * 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"); exit (1); } return NULL; } int main (void) { signal (SIGALRM, sig); pthread_t th; if (pthread_create (&th, NULL, tf, NULL)) { puts ("pthread_create failed"); exit (1); } pause (); return 0; } ?
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.
http://www.opengroup.org/austin/
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 requirements: 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? thanks -/sheryl
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 2.6.9, 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.