any comments: GUI thread safeness checker

[Alex Hunsley]

I'm planning to make a tool that AFAIK doesn't already exist, and I'm
quite surprised no-one seems to have done it yet...
It's a tool that would check that your code isn't doing GUI thread
specific things in a non GUI thread, and would warn you if it was. It
seems like a useful thing to be able to check, but I know of no tool
that yet does it, anyone know differently?

alex

 

[Dario]

I'm planning to make a tool that AFAIK doesn't already exist, and I'm
quite surprised no-one seems to have done it yet...
It's a tool that would check that your code isn't doing GUI thread
specific things in a non GUI thread, and would warn you if it was. It
seems like a useful thing to be able to check, but I know of no tool
that yet does it, anyone know differently?

What is a 'non GUI thread' ?
Please elaborate.

- Dario

 

[Alex Hunsley]

What is a 'non GUI thread' ?
Please elaborate.

Sorry, I should be specific and say "event despatch thread", which is
the thread on which component painting etc. should happen.

alex

 

[Andrew Thompson]

| I'm planning to make a tool that AFAIK doesn't already exist,

I like the sound of that..

| It's a tool that would check that your code isn't doing GUI
thread
| specific things in a non GUI thread, and would warn you if it
was. It
| seems like a useful thing to be able to check,

Yep.

| but I know of no tool
| that yet does it, anyone know differently?

Nope. (Not me, anyway)

I wish you all the best in your endeavour*,
sounds rather tricky tho'..
[ * Since I've probably got some code that
could benefit from such a tool myself! ]

 

[Gerbrand van Dieijen]

I'm planning to make a tool that AFAIK doesn't already exist, and I'm
quite surprised no-one seems to have done it yet...
It's a tool that would check that your code isn't doing GUI thread
specific things in a non GUI thread, and would warn you if it was. It
seems like a useful thing to be able to check, but I know of no tool
that yet does it, anyone know differently?

Sounds very usefull, I had numerous problems because of that (crashing
applications, etc.) but quite hard.

Also, there's some documentation on http://www.javasoft.com about that,
as far as I can recall, GUI (Swing) code outside the event-dispatch
thread isn't such a big problem as long as the components aren't yet shown
on the screen (the setVisible(true)/ show method of the container isn't
called), but that may not be such a problem.

(I'm thinking of this right now)
The tool could work by adding extra code to the source-code (of course not
necessarely in the files of the programmmer, but just in some intermediate
files) to every methods that displays or adds/changes a GUI component and
fires a runtime error if a component if the object is visible and the code
is called outside the event thread.
I think it is very hard if not impossible to do it at compile time, but
this should be quite sufficient.

 

[Alex Hunsley]

Sounds very usefull, I had numerous problems because of that (crashing
applications, etc.) but quite hard.

Also, there's some documentation on http://www.javasoft.com about that,
as far as I can recall, GUI (Swing) code outside the event-dispatch
thread isn't such a big problem as long as the components aren't yet shown
on the screen (the setVisible(true)/ show method of the container isn't
called), but that may not be such a problem.

(I'm thinking of this right now)
The tool could work by adding extra code to the source-code (of course not
necessarely in the files of the programmmer, but just in some intermediate
files) to every methods that displays or adds/changes a GUI component and
fires a runtime error if a component if the object is visible and the code
is called outside the event thread.
I think it is very hard if not impossible to do it at compile time, but
this should be quite sufficient.

This was my plan - to have my tool intrument code, temporarily, with
checks in appropriate places that checks for:
1) we're not in the GUI thread
2) we're altering something GUI wise that is displaying

With these two conditions, it would throw up some warning/information.

The other part would be for it to tell you where the GUI thread is
getting locked (for example, in an infinite loop).
Why oh why didn't sun do something like this in the first place?
Anyhoo, I let you guys know when I get some progress on this.

alex

 

[Andrew Thompson]

message ....
| Why oh why didn't sun do something like this in the first
place?

Thay did not want to gazump you Alex. ;-)

| Anyhoo, I let you guys know when I get some progress on this.

Thanx, I'll be keen to give it a test..

 

[Tony Morris]

There is nothing wrong with performing tasks on the event dispatch thread.
The problem arises when you perform <b>time consuming</b> tasks on the event
dispatch thread where the GUI will become non-responsive.
How are you going to determine whether the task is "time consuming" ?
And how are you going to determine which thread a task is running in, since
this may be completely dependant on what occurs at runtime ?

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

 

[Alex Hunsley]

There is nothing wrong with performing tasks on the event dispatch thread.
The problem arises when you perform <b>time consuming</b> tasks on the event
dispatch thread where the GUI will become non-responsive.

I'm aware of this, I think you're thinking I said something that I
didn't say!

How are you going to determine whether the task is "time consuming" ?

If I go the code instrumentation route, calls to a helper class would be
inserted to check timings for entering/exiting paintComponent and
similar items - you'd get a warning if too much time was spent in a EDT
blocking method... (e.g. paintComponent)

And how are you going to determine which thread a task is running in, since
this may be completely dependant on what occurs at runtime ?

By using SwingUtilities.isEventDespatchThread at runtime - I'm talking
about a run-time test, and not exhaustive sourcecode analysis.

alex

 

[Alex Hunsley]

message ...
| Why oh why didn't sun do something like this in the first
place?

Thay did not want to gazump you Alex. ;-)

Ah that's sooo considerate of them! I must thank them.

| Anyhoo, I let you guys know when I get some progress on this.

Thanx, I'll be keen to give it a test..

Yup, I'm giving it some thought....

 

[Tony Morris]

ok, good luck.
I assume that the definition of "time consuming" is to be a user
configurable parameter, since the definition depends on the application - or
perhaps a report of time consumed.

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

 

[Jon A. Cruz]

ok, good luck.
I assume that the definition of "time consuming" is to be a user
configurable parameter, since the definition depends on the application - or
perhaps a report of time consumed.

But there are a few things you can go by.


Anything over 1/10th of a second will be noticed by a user. Therefore
anything that could add to a chain of operations such that it *could*
total over 1/10th of a second on an average consumer machine should be
considered "potentially time consuming" and done off of the UI thread.

 

[Tony Morris]

What if I ran it on a 33MHz machine and the benchmarked "1/10" became 5
seconds ?
Hence, my suggestion to make it configurable, perhaps with a default
setting.

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

 

[Jon A. Cruz]

What if I ran it on a 33MHz machine and the benchmarked "1/10" became 5
seconds ?
Hence, my suggestion to make it configurable, perhaps with a default
setting.

No.

First of all, I don't think that would be a valid "average consumer
machine", especially since most machines with a processor that slow
don't meet the minumum specs for Java + Swing.





However, the point is that if something *could* take that long, you
*should* not have it on the UI thread at all. Not change it
conditionally at runtime.

Code inspection and simple profiling usually will point these out.

In general, the UI is there to serve the user, and the more it does just
that, the better.

What I've seen over and over is that once this type of change goes in,
programs tend to get cleaner in their architecture. And they get away
from the worst offenders who just tend to hide their head in the sand
when it comes to threads (not wanting to hear that they can't just
ignore them, since by default using Swing might get them seven or more
running around).