Re: gdb and linuxthreads (A deadlock in linuxthreads.)

[Xavier Leroy <Xavier.Leroy@inria.fr>]

Hello,

> Are you sure you sent me all the changes? I don't think it is correct.
> Did you miss something in restart.h?

No, restart.h doesn't need to be changed.  We're still using
pthread_sig_restart for suspend/restart.  The only thing we change is
the signal used to wake up the thread manager when one of its children
dies.

> Did you miss a return here? Should it be
>
>     if (self == &__pthread_manager_thread) {
>       __pthread_manager_sighandler(sig);
>       return;
>     }

Yes, you're right.

I'm currently testing my patches on a dual-PPro we have here at INRIA.
So far ex6 has run 80 times without deadlocking, but I keep trying...

> I don't think it will work with gdb. Since pthread_handle_sigcancel in
> the thread manager will call __pthread_manager_sighandler () when
> it gets a __pthread_sig_cancel, the __pthread_sig_cancel signal sent
> by gdb to indicate a new thread is created won't be processed properly.

>From LinuxThread's standpoint, that signal will cause
terminated_children to be set to 1, and the manager thread will do an
extra round of waitpid() to reap dead children.  It's inefficient, but
it won't cause any harm.

>From gdb's standpoint, the "cancel" signals sent by starting threads
will be caught as before.  But I don't fully understand what happens
with the "cancel" signals sent by terminating threads.  I've
transferred the gdb sources, applied your patches, and will try to
figure it out.

> Can we use another signal for gdb to indicate a new thread is created?
> We have RT signal in linux 2.1. It should work. We can fall back to
> __pthread_sig_cancel if RT signal is not available.

Of course, it would be best to have a third signal.  With RT signals,
that's no problem.  But if you're running on a 2.0 kernel, there
aren't many spare signals to use...  Your fallback plan is fine
provided the two-signal solution still works for those poor 2.0 users.

All the best,

- Xavier Leroy