[Python-Dev] Thread questionlet

[Christian Tismer]

Tim Peters wrote:

> [Christian Tismer]
> 
>>...
>>My question, which I could not easily answer by reading
>>the source is:
>>What happens when the main thread ends? Do all threads run
>>until they are ready too, or are they just killed away?
>>
> 
> You're walking near the edge of a very steep cliff.  There are jagged rocks
> a kilometer below, so don't slip <wink>.


Uhmm -- I really didn't want to poke into something
problematic, but obviously I have no more simple questions
left. ;-)


> It varies by OS, and even by exactly how the main thread exits.  Reading OS
> docs doesn't really help either, because the version of threads exposed by
> the C libraries may differ from native OS facilities in subtle but crucial
> ways.


It does not sound like being designed so, more like
just some way through these subtleties, without trying
to solve every platform's problems.

I don't try to solve this, either. But since I'm writing
some kind of platform independant threads (isn't it funny?
by using non-portable tricks, I get some portable threads),
I'd like to think about how this world *could* look like.
Maybe I have a chance to provide an (u)thread implementation
which is really what people would want for real threads?

>>And if they are killed, are they just removed, or do
>>they all get an exception for cleanup?
>>
> 
> Can only be answered one platform at a time.  They're not going to get a
> *Python*-level exception, no.  Here's a simple test program:


[thanks for the test code]

> I expect much the same on Linux (all threads die, no exceptions raised).
> But, IIRC, the threads would keep going on SGI despite that the main thread
> is history.


So threads do force the programmer to write platform-dependant
Python code. For sure nothing that Python wants,
it just happens.

>>...
>>When a thread ends, it may contain several levels of other
>>C calls which might need to finalize, so I thought of
>>a special exception for this, but didn't find such.
>>
> 
> Closing threads cleanly is the programmer's responsiblity across all OSes.
> It can be very difficult.  Python doesn't really help (or hinder).


Ok with me, this is really not trivial. (I guessed that from reading
the source, but it really was not obvious. So I asked a naive
question, but you know me better...)
Maybe Python could try to help though an API?


> Microsoft helps in that DLLs can define a "call on thread detach" function
> that's automatically called when a thread detaches from the DLL, but Python
> doesn't exploit that.  The DLL hook may not get called even if it did,
> depending on exactly how a thread detaches (the Big Hammer last-chance Win32
> TerminateProcess/TerminateThread functions generally leave things a mess --
> "TerminateThread is a dangerous function that should only be used in the
> most extreme cases", etc).


Now the real question:
If you have the oportunity which I have: Define some threads
which (mis)behave equally (un)well on every supported
platform, once and forever.

Would you try to mimick the median real threads behavior as
they work today? Or would you try to build something consistent,
cross-platform, that makes sense, that would even make
sense for new revisions of the real thread modules?

I think here is a chance to do a reference implementation
of (u)threads since there are absolutely no OS dictated
restrictions or MS added doubtful features, we can just
do it right. Given that there is a suitable definition
of "right", of course.

The problem is that I'm not a specialist on threading,
therefore I'm asking for suggestions.
Please, what do you all think would be "right", given that
you have full control of ver your "virtual OS"?

contructively-but-trying-not-to-overdo - ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net/
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
      where do you want to jump today?   http://www.stackless.com/