[Dieter Maurer]
You have snipped my explanation why I am convinced that the patch can only improve things!
Yes, because zope-dev isn't a useful place to discuss this complicated Python issue. If you missed it the first two times <wink>, let me suggest again that you add your comments to the bug report: that's the only place where the people fixing this problem, and the people making the release decisions, will see what you have to say (I have no say in what happens here, and I'm not working on resolving this issue either -- all I did is agitate to "do something" for 2.3.4, but I lost that battle).
I have not argued that there was no case to block *some* signals,
As the discussion in the bug report makes clearer, it's unclear whether Python "should be" blocking any signals anywhere.
just not the ones that the operating system uses to signal major problems -- SIGSEGV, SIGBUS, ... and friends. The patch states that the pthreads standard says that such signals should not be blocked.
This is a Python issue independent of the bug in LinuxThreads.
Python has its own threading model, which has to work across several thread implementations besides just pthreads. It doesn't *intend* to mimic the native platform thread gimmicks, it has to build on them. If LinuxThreads handled signals correctly (according to the pthreads standard), there wouldn't be a problem here.
Our system administrators have been sceptical to switch to NPTL support. They say, there are still some problems about it.
I don't know, but most things I've read about the *current* NPTL are very positive (orders of magnitude faster in some stress tests than LinuxThreads, and much better conformance to the standard). Earlier versions of NPTL got worse press.
I will reraise the question and see what my colleagues feel as the less problematic way: use NPTL or our own Python version.
It would sure help if people running Zope on an NPTL system spoke up here!