1

I'm sorry that this question is a bit vague but I've not been able to get any useful info from debugging.

I have a thread that I call using new Thread().Start, it will then run for a a short time and I receive this message:

Uncaught exception:Application "my app name(201)" is not responding; process terminated

Now what's frustrating is I am able to run the same process but without a thread, which then locks up my Application but I can see from my Eclipse console that its working without error. So I know their isn't an error with the functions I'm using on the Thread.

I thought perhaps the issue might lie with me using a "InvokeLater" function to update my GUI with the threads progression, I am spamming this pretty hard and I fear its destroying my thread.

Any suggestions?

To expand upon my post, the issue was due to me calling this code ALOT from my other thread:-

 invokeLater(new Runnable() 
        {
            public void run() 
            {
                _output.setText(_output.getText() + "\n" + msg);
            }
        });

This was building up a queue that quickly crashed my application.

My solution to the option was to use the event thread by adding this code to my function:-

   synchronized(Application.getEventLock()) {
       _output.setText("new text " + System.currentTimeMillis());
   }
Demonofloom
  • 240
  • 4
  • 17
  • 2
    You might want to post some code to show what your Thread does. – no.good.at.coding May 16 '11 at 20:51
  • Are you sure you're using invokeLater() and not invokeAndWait()? I've fallen into that one before when I was using autocomplete. Also I agree with NGAC, some code would be incredibly helpful. – jprofitt May 16 '11 at 21:25
  • Based on your edit, I want to point out that your original code is quadratic, while the replacement code is linear, so you can't compare them on performance. – Michael Donohue May 17 '11 at 16:26

3 Answers3

1

If you are synchronized on some object within the thread while doing something time-consuming, and if your UI thread attempts to synchronize on the same object, it will block until the lock is released.

Ted Hopp
  • 232,168
  • 48
  • 399
  • 521
1

You're exactly right:

I thought perhaps the issue might lie with me using a "InvokeLater" function to update my GUI with the threads progression, I am spamming this pretty hard and I fear its destroying my thread.

Calling InvokeLater returns immediately, and queues work for the UI thread to execute. The problem is that if that queue gets too big, the OS will kill your app, assuming that the UI has bogged down to the point where it is not servicing the queue.

The solution I've used to get around this in the past is to chunk the work being sent to the UI thread. Make some sort of accumulator object, and boolean flag, and a lock. The worker thread then grabs the lock and adds work to the accumulator. The boolean flag indicates whether the UI worker code is scheduled to empty the accumulator in the future. If not, schedule your UI update code.

In the UI update code, you grab the lock and move the data out of the accumulator as quickly as possible, and mark the boolean as false, to show that there is no longer a UI worker scheduled to empty the accumulator.

Michael Donohue
  • 11,776
  • 5
  • 31
  • 44
0

It could be a deadlock, especially if you extend the timeout and still see it. You could take a thread-dump and see what the UI thread is doing. If it's waiting to acquire a lock, you'd probably want to dig in this direction.

Enno Shioji
  • 26,542
  • 13
  • 70
  • 109