This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: linuxthread race condition


> There is a race condition in linuxthreads during thread creation on
> architectures that use a dedicated thread register.  Between the point the
> thread is created and inserted in the list of active threads, and the
> point the thread register is initialized in the child a cancel signal may
> arrive, with the thread manager calling pthread_handle_exit.
...
> To fix this race I have blocked the cancel signal in the manager around
> the clone call, so that the child does not call the signal handler before
> thread_self is initialized.

Wouldn't it be enough to check for this special case in
pthread_handle_sigcancel(), like so:

static void pthread_handle_sigcancel(int sig)
{
  pthread_descr self = thread_self();
  sigjmp_buf * jmpbuf;

  if (self == &__pthread_manager_thread)
    {
      if (thread_self_stack() == &__pthread_manager_thread)
        {
	  __pthread_manager_sighandler(sig);
          return;
        }
      /* Oops, thread_self() isn't working yet..  */
      self = thread_self_stack();
    }
...

with thread_self_stack() being the current 'normal' thread_self().

I'd rather see cancellation becoming a little slower than every
pthread_create() requiring two more system calls.

Regards,
Wolfram.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]