> 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
> 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!
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -