Serializing PyThreads without holding interpreter lock?
Martin v. Löwis
martin at v.loewis.de
Tue Mar 18 21:33:52 CET 2003
Albert Hofkamp <hat at se-46.wpa.wtb.tue.nl> writes:
> > I recommend to put another lock around the solver code. See
> > _tkinter.c for an example; it also puts Tcl into a lock. This
> > requires a few additional macros, since you need a state where you
> > hold both locks, and a state where you just hold the solver lock.
> Tnx for the pointer.
> Luckily, my situation is somewhat easier because the solver is not
> multi-threaded. (phew!)
Neither is Tcl, and this precisely is the reason to add the lock
(this isn't really true for Python 2.3, so you should look at the 2.2
> I just checked again, PyThread_lock_type, PyThread_acquire_lock, and
> PyThread_release_lock are _NOT_ in the (index of the) C/API manual and
> neither are they in the embedding/extending manual, at least I couldn't
> find them.
That is correct.
> Maybe there are other manuals that describe thread-programming in Python?
No, it is just undocumented. Contributions are welcome; please send
patches to sf.net/projects/python.
More information about the Python-list