Embedding and threads ?

[Bo Lorentsen]

On Sun, 2002-06-02 at 11:35, Martin v. Löwis wrote:

> I see. This is necessary indeed. The builtins are normally inherited
> from some context when doing "exec" or "eval" at the Python level; on
> the C API, no such inheritance happens automatically.
Ok, I see. Its just that I assumed that the interpreter state was more
isolated, regarding real threads, because of this.
For me it looked more like the library had i thread problem than the
core interpreter.

> Nearly everything in Python
> - changing and accessing dictionaries
> - changing and accessing lists
> - writing to files
> - allocating memory (atleast with pymalloc)
Ok, so the word "everything" is really more appropriate :-)

> etc. None of these operations is thread-safe per se; it is only the
> GIL that prevents breakage.
And only one CPU thread can execute it at a time. As You may have more
threads but only one can execute Python code at a time, because the GIL
will serialize the execution !

> > Arhh, so Python can execute in a MT environment, but only one
> > interpreter at a time, the rest is pseudo MT ?
> 
> I don't think I understand this question. As I said before, restrict
> yourself to "one interpreter" (in the sense of PyInterpreterState*).
> This is the normal case even in the presence of threads.
What I meant is that, it is only possible to make threads that are
software scheduled (Python (and its lib functions) deside when to
release the GIL), and if I try to use real threads the result will still
be limitet by this software threading.

> I don't know what pseudo MT is (in what sense is it pseudo?). It
> certainly has multiple concurrent threads.
I'm not sure it a proper term, but this is how I se it : software thread
= pseudo thread

Pseudo, is because it can't really take advantage of SMP (or the system
process scheduler), and its the software that controlles the
"scheduling".

> For most people, it is "real" MT today, since they have only one
> processor in their computers, anyway.
I know, and as for now I don't know how important it is for me. But as I
looked into the Python interface, I was in the beginning hoping that the
threads was more "naturly" implimentet in the language engine, and I was
hoping to take advantage of this in the future :-) 

> To make it "more real", you would have to introduce what is known as
> "free threading". People have tried this (ask Google) and found that
> it slows down the interpreter significantly.
Hmm, this sounds like they had not done it the proper way :-) But I will
take a look in Deja/Google !

But ok, I'll use what Python provide, and I'm sure it will work out just
fine, and then I'll see hov things in Python progress regarding threads
in the future :-)

/BL