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