Tim Peters wrote:
... 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