[Python-Dev] Extension modules, Threading, and the GIL

Mark Hammond markh@skippinet.com.au
Thu, 9 Jan 2003 10:10:46 +1100


[David]

> I think I'm done arguing about this.  If Mark isn't discouraged by
> now, I'm still ready to help with the PEP.

No, I saw this coming a mile off :)  A little like clockwork really.

Martin seems to be trying to make 3 points:
1) There is no problem.  All Windows API function that could indirectly send
a Windows message are clearly documented that they generate messages, and if
they arent then it is all MS' fault anyway.  Substitute "Windows" and "MS"
for the particular problem you are having, and we have a nice answer to
every potential problem :)

2) Even if such a problem did exist, then creating a brand new thread-state
for each and every invocation is acceptable.

3) Mark stated performance was secondary to correctness.  Therefore, as soon
as we have correctness we can ignore performance as it is not a primary
requirement.

(1) is clearly bogus.  As with David, I am not interested in discussing this
issue.  David, Anthony and I all have this problem today.  Tim Peters can
see the problem and can see it exists (even if he believes my current
implementation is incorrect).  All due respect Martin, but stick to where
your expertise lies.

As for (2):  My understanding (due to the name of the object) is that a
single thread should use a single thread-state.  You are suggesting that the
same thread could have any number of different thread-states, depending on
how often the Python interpreter was recursively entered.

While I concede that this is likely to work in the general case, I am not
sure it is "correct".  If no threading semantics will be broken by having
one thread use multiple thread-states, then I must ask what purpose
thread-states (as opposed to the GIL) have.

Mark.