Python threads question

[Makhno]

>Close, but no ceegar.  There are indeed multiple native threads, but
>there is a lock that prevents more than one from running Python code at
>any time.  That lock is switched to another thread roughly every ten
>bytecodes (that number is changeable, though) by the Python interpreter
>itself as it operates on bytecodes.

I see. That makes some sense then.

>Quite the contrary.  Thread-safe external code can *release* that lock;
>as I said in another post just now, all the blocking I/O calls in Python
>do this automatically.  The only gotcha here is that if you have an
>external function that does *not* release the lock, it doesn't go
>through the section of the Python interpreter that switches between
>threads, so other Python threads are blocked.  You need to re-acquire
>the interpreter lock when you want to communicate with the Python
>interpreter.

Sounds easy enough. The underlying code should be sufficiently thread-safe
for me to do what I want.
Deadlocking would be a worry though with all this blocking and reaquiring
going on.

>I'll skip responding to the rest of your post to give you some time to
>rethink how you're handling stuff.

Thing is, it's already been handled. The GUI tool has already been written
to support Perl, but before I 'freeze' that interface, I wanted to look at
the future for when I write the Python interface.

>Note^2: One of the side effects of Christian Tismer's Stackless Python

What I tried doing with a non-multithreaded Perl interpreter was creating a
'virtual' thread. Essentially a background calculation could run, but it
periodically called a certain function which simply released the lock I had
placed around the interpreter then tried to aquire it.
Not quite multithreading as when one thread was running in the Perl
interpreter the rest would be locked out, but it was good enough for what I
wanted to do.
This idea failed though when I tried to create more 'threads' in this way.
The Perl stack got confused.
I'd pretty sure I could do the same hack with the Python interpreter, but I
don't like it, and wanted to see if there's some other way (when threads
become an option on Perl, I'll look at those too). It certainly looks like
it if Python threads are indeed 'real' OS-level threads.
Can I ask how the switching is achieved? Presumably a thread just counts
upto 10 bytecodes then releases its lock, and immediately tries to require
it.

>primarily an issue if you need to distribute
>your application or have an organizational policy against non-stock
>patches.

'organisation' ? not me, I'm working on it on my own in my flat. But I'd
rather not have to make the user change his interpreter (not including
getting the latest) so I won't look into stackless threads.


It certainly looks as though I want to call the Py_BEGIN_ALLOW_THREADS
everytime I call a function in my extension. This way, the threads can
continue working while the GUI is being manipulated (or just blocking for
user input).