[Zope-dev] Segfault and Deadlock

[Tim Peters]

[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>.