[Zope-dev] Segfault and Deadlock
Tim Peters
tim at zope.com
Mon May 3 22:23:13 EDT 2004
[alangmead at boston.com, on special-casing LinuxThreads]
> I might be willing to try my hand at this, but I could use a tiny bit of
> guidance. (If you don't mind.)
I don't mind <wink>, but I haven't run on Linux since 1994, and have lost
track of how Unixish special-casing is done in Python since then. Best
advice is to start with a bug report on Python's bug tracker, and perhaps a
msg to mailto:python-dev at python.org
I think Martin v. Löwis is currently most knowledgeable about messy config
issues in Python.
> It seems that the patch should only be activated for LinuxThreads, and
> should be tested for in configure.
Sounds plausible, but I wouldn't know.
> 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"?
I don't know what's available in LinuxThreads *to* test. Most packages have
some God-awful preprocessor #define to key off of. Also don't know whether
the specific breakage at issue here is unique to LinuxThreads.
> 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.
I expect that's why most people settle for testing a package-specific
#define. It's also why there's always at least some resistance to patches
that do key off goofy symbols: the #ifdef'ed code will probably remain
there forever, regardless of whether the problem still exists. So:
> 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.)
An autoconf-able test that checks for the actual bad behavior would be best.
...
> Is it reasonable to put a LinuxThreads specific replacement
> SET_THREAD_SIGMASK in thread_pthread.h?
Yes.
> There are already a slew of system specific defines, and the
> differences don't seem extreme enough to make a separate
> thread_linuxthreads.h
Fully agreed. LinuxThreads is primarily pthreads with a bug. That makes it
qualitatively the same as all other pthreads implementations <wink>.
More information about the Zope-Dev
mailing list