New to Python; be gentle if I've simply missed something. i'M running on Windows XP, using a recently downloaded 2.7.1. I'm running by hitting F5 in IDLE.

The attached .py creates 2 threads, one which updates a Tkinter label 10 times a second forever, and one which sleeps for a second and then thrashes the CPU for ~4 seconds, forever. I wrote this to see how Python dealt with CPU-pig threads, and was pleased to see both threads got to run in a decently interleaved way, even in the face of a tight loop.

But at a random point, one of the threads (which one varies) stops running. The other continues fine. The problem manifests in less then 5 minutes (often less than 1).

At least once, but not ever time, the thread that stopped gave a traceback:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "D:\Python27\lib\threading.py", line 530, in __bootstrap_inner
    self.run()
  File "F:\Python27\MyProjects\e.py", line 24, in run
    print "evil!"              #<--- point 1
  File "D:\Python27\lib\idlelib\rpc.py", line 595, in __call__
    value = self.sockio.remotecall(self.oid, self.name, args, kwargs)
  File "D:\Python27\lib\idlelib\rpc.py", line 211, in remotecall
    return self.asyncreturn(seq)
  File "D:\Python27\lib\idlelib\rpc.py", line 240, in asyncreturn
    response = self.getresponse(seq, wait=0.05)
  File "D:\Python27\lib\idlelib\rpc.py", line 280, in getresponse
    response = self._getresponse(myseq, wait)
  File "D:\Python27\lib\idlelib\rpc.py", line 305, in _getresponse
    cvar = self.cvars[myseq]
KeyError: 8680

BUT in some cases there wasn't a traceback (the last time there wasn't, it was BThread that had stopped running; the label was no longer updating.)

If you comment out the print at point 2, or point 1, it seems to work fine, at least for as long as I cared to watch it.

Also, I've noticed that if I close the app's window, that at least one thread keeps running and writing to the Python shell console. (One generally dies because the Tkinter label has gone away). They are both marked as daemonic; shouldn't they stop more or less instantly?

What happens if you run your program without IDLE? 
(either with right-click and run or run from Command Prompt window?) 

I would not be surprised if your problems go away. IDLE runs a saved file in a separate pythonw process. Printing (or writing) to stdout requires sending output back to the IDLE process. I can imagine that doing that from 2 subthreads could lead to conflicts.

If the problems do go away, then we should probably close this as won't fix. IDLE is a development environment, not a production running environment

It hasn't failed yet when run "straight".

Here's the issue, though. I'm going to be introducing Python as the scripting language of choice, to a bunch of people who are less than fluent in programming. Because debugging is not an obvious concept to them, they are going to hunt for problems by sticking in print statements everywhere, and the environment is inherently multithreaded, so it's hard for me to imagine they won't experience this bug. I hit it in my very first multithreaded experiment. And I can't possibly ask them not to use IDLE - without syntax coloring and a friendly editor to show them which line is wrong, they will never get off the ground.

It would be tolerable if there was at least a traceback, but if threads vanish silently, they will not realize it's a environment problem; they will either assume that they did something inexplicably wrong and that "scripting is too hard", or it will get around that I provided a "broken" solution.

So even if it's "just the IDE", it's still life and death for this project. "Won't fix" probably means I have to abandon Python.

FWIW, I downloaded, edited for 3.2, and ran. 45 minutes later, with counter in box near 16000, and output sequence looking about the same as initially, I killed with Task Manager (also on winxp). You might try same on your system.

I ran the 2.7 file (on 2.7) and after several minutes, threadA stopped printing, but no error message.

Antoine, could improvement from 2.7 to 3.2 have anything to new with the new implementation of the Global Interpreter Lock?

Scott, if you can do your project with 3.2, I strongly recommend it. Even with 2.7, one can run files outside of IDLE even though you edit with IDLE. You just give up the F5 convenience. Or, I believe there are other editors without a shell which do so directly. Or, you could write a dp() (debug print) function that writes to a scrolled window in your toplevel app window (where running numbers appear now.

Moving to 3.x means redoing large swaths of the extension I just wrote. It's only a couple thousand lines, but it was my first extension and it cost me a week of my life in Google, and it does a lot with strings.

I haven't pulled down the source code for Python's internals yet, but from the one trace back I did get in the failing thread test app, the problem was inside print and it looked like it was inside the mechanism where print gets redirected. I hope the problem isn't anything as fundamental as the GIL, because that throws the stability of all of 2.7 into question (and it's been solid in all my tests; I do a lot with threads in my extension, all going after the GIL and diving into Python code.)

> Antoine, could improvement from 2.7 to 3.2 have anything to new with
> the new implementation of the Global Interpreter Lock?

Perhaps, but then it's pure luck. 
Looking at the traceback, IDLE seems to replace sys.stdout with its own thingie when spawning a separate Python program. Perhaps that thingie isn't thread-safe.

Is this issue reproduced now, with Python 2.7.3+?

Is this issue reproduced with issue9290 patch?

I re-ran in 2.7.3. First time, B froze at 81, second time neither froze for a few minutes until I used task manager to stop. I then remembered that accessing the gui from a 2nd thread is not supported.

Quoting from msg179101 on #16823, which I turned into a doc issue:
'''
What you are doing appears to be unsupported (invalid). From
http://www.astro.washington.edu/users/rowen/TkinterSummary.html
"all Tkinter access must be from the main thread (or more precisely,
from the thread that calls the mainloop). Violating this is likely to
cause nasty and mysterious symptoms such as freezes and core dumps."
'''
You got the unpredictable random freeze part. But perhaps the quote is wrong (#11077).

But to be sure that was the problem, I reran with B's gui access commented out. It stopped again as about 500. So there is a problem with just printing.

I tested 3.3 and stopped it with TaskManager at 18000 and A still running too.

> Is this issue reproduced with issue9290 patch?

That was just last January. Unless and until I can get new executable with a working tkinter, I cannot test that and other recent patches. Let's hope that 3.2/3.3 still run correctly.

If there is no bug in 3.6/7, this should be closed.

In 3.6.2rc1, the counter has reached nearly 40000 after 40 minutes.  So no  bug in current 3.x.  I ran a couple of times with 2.7 and got 3000-4000 both times.  I am no longer patching IDLE for 2.7, so closing.

I have since learned the following about accessing tk widgets from non-main threads.
1. It seem to be reliable when tcl/tk is compiled with thread support but not when tcl/tk is not so compiled. (The latter is contrary to a claim in the doc.)
2. The tcl default is 'without' 8.5 and 'with' for 8.6, and PSF installers follow the default.  I am guessing that this is likely true for Linux distributions.
3. The 2.7 Windows installer currently includes 8.5.15.  The 3.5+ Windows installers include 8.6.z.  Hence the different results on my Windows machine.
4. Mac installers now use 8.6.z even, I believe, for 2.7.  I have the impression that the system tcl/tk for current Linux distributes is also 8.6.z.
Hence, the issue of tkinter thread safety is resolving itself.

I reran e10909.py with 2.7.16 with the B config call disabled and it ran until I stopped it at 24 minutes.  Printing from a thread is not an issue on my machine.