[EMAIL PROTECTED], 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:[EMAIL PROTECTED] 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>. _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )