"Tim Peters" <tim@zope.com> wrote on 05/03/2004 04:41:08 PM:
[alangmead@boston.com]
If someone cares enough to work up a patch, Python's patch tracker is open all night:
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.