[Zope-dev] Segfault and Deadlock

alangmead at boston.com alangmead at boston.com
Mon May 3 18:57:24 EDT 2004





"Tim Peters" <tim at zope.com> wrote on 05/03/2004 04:41:08 PM:
> [alangmead at boston.com]
>
> If someone cares enough to work up a patch, Python's patch tracker is
open
> all night:
>
>     http://sf.net/tracker/?atid=305470&group_id=5470

I might be willing to try my hand at this, but I could use a tiny bit of
guidance. (If you don't mind.)

It seems that the patch should only be activated for LinuxThreads, and
should be tested for in configure.

Is it reasonable to test for a LinuxThreads specific function (like
pthread_kill_other_threads_np). Should I create a functional test that
test tries to cause  the LinuxThread specific behavior (cause a deadlock)
and the notice the problem and fix it.Should I use the glibc feature
"getconf GNU_LIBPTHREAD_VERSION"?

The first is easiest to test for, but seems a little error prone. (what if
someone else adds the non-standard function in order to ease porting from
Linux? What if someone comes up with a LinuxThreads update that solves this
problem?)  Its testing a feature that is related to the feature I want info
for, but not the troublesome behavior itself.

The second solution seems to be one step away from the halting problem
(although it might be able to be done with "block signal_a, send signal_a,
send signal_b, if signal_b is caught but not signal_a, then signals are not
rerouted across threads.)

The third option seems to be somewhere between the two (If getconf exists
and the symbol doesn't, then we have older linuxthreads. If the getconf
exists and the symbol returns linuxthreads, then we have newer
linuxthreads. Otherwise assume a compliant pthread.)


Is it reasonable to put a LinuxThreads specific replacement
SET_THREAD_SIGMASK  in thread_pthread.h? There are already a slew of
system specific defines, and the differences don't seem extreme enough to
make a separate thread_linuxthreads.h

This has, of course, long veered off from being about zope development, so
anyone wishing to contact me off list, feel free.




More information about the Zope-Dev mailing list