[Zope] Re: zope2.6.4/python2.2 doesn't restart after crash, with python2.1 it does

[Tim Peters]

[Tim Peters]
>> I like #3 best <wink>.  Volunteers to work on Python 2.2 vanished long
>> ago, and chances are good 2.3.5 will be the last release in the 2.3
>> line (2.3.5 will come out after 2.4, probably before this year ends).
>> I don't know whether anyone did #1, but if not, there isn't much time
>> remaining to do so before 2.3.5.

[Andrew Langmead]
> The realinesigs7.patch in
> <https://sourceforge.net/tracker/?
> func=detail&aid=960406&group_id=5470&atid=305470> is pretty close to
> what Michael Hudson committed to 2.4, and applies pretty cleanly to
> 2.3.4. Someone well connected to the python development community
> <wink> might want to lobby for that change to be backported to the 2.3
> branch. If someone wants a patch made that consists precisely of the
> changes mwh put into 2.4, I might be able to work that up.

The good news is that backporting bugfixes isn't a matter of lobbying.
 Changes didn't get made for 2.3.4, despite lobbying, because there
wasn't yet agreement at that time about what *should* be done.  It was
trying to ram in 2.3.4 changes in the absence of agreement that
required lobbing then, and that lobbying failed (and it should have
failed).

The bad news is that backporting bugfixes is almost purely a "scratch
your own itch" thing -- backports happen if, and only if, someone
volunteers to do all the work.  If you volunteer to produce an
appropriate patch for 2.3.5, upload it and set the priority to 9. 
I'll run interference then <wink> to assure it doesn't get dropped on
the floor.  It sounds like mwh should be assigned as the reviewer.

>> Wasn't this specific problem also unique to LinuxThreads?  That is,
>> weren't Linux systems with POSIX-conforming NPTL threads immune to it?
 
> At first it seemed that way, or at least I came up with a Linux
> specific work around.

By "this specific problem", I mean only the business about Zope not
being able to restart after some kinds of crashes.  A Zope
installation shouldn't care, e.g., whether Python's insane interface
to GNU readline's insane implementation works in every endcase.

> After I was knee deep in things, I discovered that the root cause came down
> to two things. 1) That Modules/readline.c was working in a non-thread-safe
> way (setting a signal handler that would longjmp() back out of the readline
> library, ignoring the fact that the thread that handled the signal may not have
> been the one that entered readline) and 2) That 2.2 tried to fix the readline
> problem by blocking all but the main thread, which would be the only one to
> use readline.
>
> What 2.4 chances do do is back out of the 2.2/2.3 behavior of blocking
> signals on threads, resuming the 2.1 behavior. (The C signal handler
> runs on any thread, sets a flag, and the main thread runs the python
> handler at the next available moment.) and then changed
> Modules/readline.c to be thread-safe (and then thankfully Michael
> Hudson fixed my fix.)
>
> Since all the problems were pthread/signal related, I guess another
> possibility would be to use a python with threading other than pthreads
> (the GNU pth library. Win32, Mac OSX's mach threads, etc.) but the
> suggestion to change deployment platforms seems pretty severe.

By most accounts I've seen, current NPTL is favored over LinuxThreads
on all counts anyway.  I don't feel bad about recommending that people
fix their problems as a side effect of improving their lives <wink>.