Bug 118044 - Bug in NPTL regarding POSIX signal handling
Bug in NPTL regarding POSIX signal handling
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
high Severity medium
: ---
: ---
Assigned To: Roland McGrath
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-11 08:43 EST by Need Real Name
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-23 21:20:31 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)

  None (edit)
Description Need Real Name 2004-03-11 08:43:59 EST
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:
Comment 1 Elliot Lee 2004-03-11 12:25:29 EST
glibc, not tftp
Comment 2 Jakub Jelinek 2004-03-11 12:40:59 EST
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;
}

?
Comment 3 Jakub Jelinek 2004-03-11 12:53:35 EST
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.
Comment 4 Jakub Jelinek 2004-03-11 12:54:24 EST
http://www.opengroup.org/austin/
Comment 5 Roland McGrath 2004-03-11 16:24:00 EST
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.
Comment 6 David Lawrence 2004-03-15 13:52:33 EST
Changing product and version.
Comment 7 Roland McGrath 2004-03-19 20:58:07 EST
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.  
Comment 8 Need Real Name 2004-07-12 02:30:58 EDT
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.
Comment 11 sheryl sage 2004-07-27 14:19:14 EDT
Can we have an update on when in 2.6 you are looking at fixing this?

thanks 
-/sheryl
Comment 12 Roland McGrath 2005-04-23 21:20:31 EDT
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.

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