RE: [Zope-dev] Segfault and Deadlock

For another way round this issue of segfaults and deadlock when using python 2.2, has anyone tried running Zope with a python built to use the GNU Pth library instead of the system's pthread library? GNU Pth is an entirely user-space library, so I would think it's behavior would remain consist

RE: [Zope-dev] Segfault and Deadlock

I've submitted two patches to the python patch collector is something that should probably work with any pthreads based Unix implementation. It simply unblocks the type of signals that are normally del

RE: [Zope-dev] Segfault and Deadlock

Carl Witty <[EMAIL PROTECTED]> wrote on 05/04/2004 08:18:52 PM: > I don't think it should be tested for in configure (or at compile-time > at all). People will want to have binary distributions that work both > with LinuxThreads and NPTL; some people actually switch back and forth > on an appl

RE: [Zope-dev] Segfault and Deadlock

On Mon, 2004-05-03 at 15:57, [EMAIL PROTECTED] wrote: > > > "Tim Peters" <[EMAIL PROTECTED]> wrote on 05/03/2004 04:41:08 PM: > > [EMAIL PROTECTED] > > > > If someone cares enough to work up a patch, Python's patch tracker is > open > > all night: > > > > http://sf.net/tracker/?atid=305470&gr

RE: [Zope-dev] Segfault and Deadlock

As Andrew Langmead has already discovered, the LinuxThreads issue with SIGSEGV was reported on the Python bug tracker almost a year ago (well, reported, but not diagnosed): SIGSEGV causes hung threads (Linux) http://www.python.org/sf/756924 Looks like: can't CNTRL-C when running os.s

RE: [Zope-dev] Segfault and Deadlock

[EMAIL PROTECTED] [... snip good explanations ...] > In order to get LinuxThreads to support the Python's threading > semantics, what probably needs to be done is to have > PyThread_init_thread set all handlers to call kill(main_thread, sig) > to signal the main thread. If someone cares enough t

RE: [Zope-dev] Segfault and Deadlock

"Tim Peters" <[EMAIL PROTECTED]> wrote on 05/03/2004 04:41:08 PM: > [EMAIL PROTECTED] > > If someone cares enough to work up a patch, Python's patch tracker is open > all night: > > http://sf.net/tracker/?atid=305470&group_id=5470 I might be willing to try my hand at this, but I could use

RE: [Zope-dev] Segfault and Deadlock

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

RE: [Zope-dev] Segfault and Deadlock

"Tim Peters" <[EMAIL PROTECTED]> wrote on 05/03/2004 03:47:31 PM: > [Dieter Maurer] > I'm not clear on exactly what "blocked" means. It has a very specific meaning with Unix signals. The kernel still has the signal for the process waiting in a queue, but the process has told the kernel that

RE: [Zope-dev] Segfault and Deadlock

[Dieter Maurer] > The reason why I believe Python is to blame: Then this should really move to a Python bug tracker. > With Python 2.1.3, a SIGSEGV in one thread killed them all; > with Python 2.3.3, a SIGSEGV in one thread kills one > of them (the main thread, not the thread that got the S

RE: [Zope-dev] Segfault and Deadlock

Dieter Maurer <[EMAIL PROTECTED]> wrote on 05/03/2004 01:48:57 PM: > The reason why I believe Python is to blame: > > With Python 2.1.3, a SIGSEGV in one thread killed them all; > with Python 2.3.3, a SIGSEGV in one thread kills one > of them (the main thread, not the thread that got t

RE: [Zope-dev] Segfault and Deadlock

Tim Peters wrote at 2004-5-2 23:16 -0400: > ... >Suppose a thread dies while holding the GIL (Python's global interpreter >lock). Will the GIL be released so that another thread (including the main >thread) can continue? There's no general answer to that. I expect that >under *most* platform thr

Re: [Zope-dev] Segfault and Deadlock

Dieter Maurer <[EMAIL PROTECTED]> wrote on 05/02/2004 01:28:48 PM: > Willi Langenberger wrote at 2004-5-2 17:10 +0200: > > What is "NPTL"? It stands for "Native POSIX Thread Library" It is a new threads subsystem that is included in Linux 2.6 that Red Hat has backported into their 2.4 kerne

RE: [Zope-dev] Segfault and Deadlock

[EMAIL PROTECTED] > Hi Zope (and Python) experts! > > There seems to be a problem when an external python module segfaults > during a zope request. The remaining worker threads are deadlocked. Maybe, maybe not. Python (and so also Zope) use platform-native thread facilities, and what happens when

Re: [Zope-dev] Segfault and Deadlock

Am 2. Mai 2004 um 13:28 schrieb Dieter Maurer: Willi Langenberger wrote at 2004-5-2 17:10 +0200: ... The reason is the way python handles threads on some systems (RedHat-7.3, kernel 2.4.20, without NPTL). What is "NPTL"? The "native posix thread library" or something like that. It's a new threadi

Re: [Zope-dev] Segfault and Deadlock

According to Dieter Maurer: > >The reason is the way python handles threads on some systems > >(RedHat-7.3, kernel 2.4.20, without NPTL). > > What is "NPTL"? Native POSIX Thread Library. > That is the good behaviour. Thus, we only have to learn > how we can get "NPTL" for all Linux systems. How

Re: [Zope-dev] Segfault and Deadlock

Willi Langenberger wrote at 2004-5-2 17:10 +0200: > ... >The reason is the way python handles threads on some systems >(RedHat-7.3, kernel 2.4.20, without NPTL). What is "NPTL"? >... >PS: A RedHat-9 system (kernel 2.4.20, with NPTL) shows a different >behaviour. After the segfault, all threads di