Andi,
Does this mean Python 2.3.5 is officially supported now? If
so I can build Python 2.3 packages for Debian as well.
-matthew
Andi Vajda [EMAIL PROTECTED] said:
>
> On Fri, 3 Mar 2006, Matthew O'Connor wrote:
>
> >Python 2.3.5 has that patch applied.
> >
> >-matthew
>
> That is most excellent news. This means that Python 2.3.5 can be supported
> with PyLucene. One still needs to build PyLucene for that version since the
> binaries I produce are all built with Python 2.4 header files.
>
> Andi..
>
> >
> >Andi Vajda [EMAIL PROTECTED] said:
> >
> >>
> >>On Fri, 3 Mar 2006, Bill Janssen wrote:
> >>
> >>>>There was a threading issue in Python 2.3 that would cause deadlocks. It
> >>>>got
> >>>>fixed sometime after 2.3.4 and is fixed in 2.4. I don't know if it is
> >>>>fixed in
> >>>>2.3.5, it could be. If you're not using threads, you should be fine.
> >>>
> >>>Unfortunately, I am using threads. This is a big deal for Mac users,
> >>>as I doubt we'll be free of 2.3.5 till the end of 2007, realistically.
> >>>
> >>>Here's a list of the 4 threading issues fixed in 2.3.5. Was it one of
> >>>these?
> >>
> >>I don't know if it was one of these but the patch below seemed to have
> >>fixed it. What do the Python 2.3.5 sources say ?
> >>
> >>--- threadmodule.c.orig 2004-08-17 12:39:30.664412784 +0100
> >>+++ threadmodule.c 2004-08-17 12:40:16.105504688 +0100
> >>@@ -425,11 +425,10 @@
> >> t_bootstrap(void *boot_raw)
> >> {
> >> struct bootstate *boot = (struct bootstate *) boot_raw;
> >>- PyThreadState *tstate;
> >>+ PyGILState_STATE gstate;
> >> PyObject *res;
> >>
> >>- tstate = PyThreadState_New(boot->interp);
> >>- PyEval_AcquireThread(tstate);
> >>+ gstate = PyGILState_Ensure();
> >> res = PyEval_CallObjectWithKeywords(
> >> boot->func, boot->args, boot->keyw);
> >> if (res == NULL) {
> >>@@ -454,8 +453,7 @@
> >> Py_DECREF(boot->args);
> >> Py_XDECREF(boot->keyw);
> >> PyMem_DEL(boot_raw);
> >>- PyThreadState_Clear(tstate);
> >>- PyThreadState_DeleteCurrent();
> >>+ PyGILState_Release(gstate);
> >> PyThread_exit_thread();
> >> }
> >>
> >>Andi..
> >>
> >>>
> >>>Bill
> >>>-------------------
> >>>
> >>>Bug #1055820: Cyclic garbage collection was not protecting against that
> >>>calling a live weakref to a piece of cyclic trash could resurrect an
> >>>insane mutation of the trash if any Python code ran during gc (via
> >>>running a dead object's __del__ method, running another callback on a
> >>>weakref to a dead object, or via any Python code run in any other
> >>>thread that managed to obtain the GIL while a __del__ or callback was
> >>>running in the thread doing gc). The most likely symptom was
> >>>"impossible" AttributeEror exceptions, appearing seemingly at random,
> >>>on weakly referenced objects. The cure was to clear all weakrefs to
> >>>unreachable objects before allowing any callbacks to run.
> >>>
> >>>Bug #875692: Improve signal handling, especially when using threads,
> >>>by forcing an early re-execution of PyEval_EvalFrame() "periodic" code
> >>>when things_to_do is not cleared by Py_MakePendingCalls().
> >>>
> >>>Bug #993394: A KeyError was being raised by Thread.__delete() for
> >>>dummy_threading when called by atexit if an instance of Thread was
> >>>created in an interpreter running in -O. The exception was of no
> >>>importance and thus is now thrown away if raised.
> >>>
> >>>Bug #754449: threading.Thread will no longer mask exceptions raised
> >>>during interpreter shutdown with another exception caused by
> >>>attempting to output the initial exception. This fix also includes a
> >>>backport of rev. 1.41 from HEAD.
> >>>
> >>>
> >>_______________________________________________
> >>pylucene-dev mailing list
> >>[email protected]
> >>http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
> >>
> >
>
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
