Re: I need a different approach - suggestions please
Arne Vajh=F8j wrote:
Lew wrote:
Arne Vajh=F8j wrote:
Lew wrote:
markspace wrote:
bilsch wrote:
Many things are because I mimic what I see in other programs... I
hope I can finish this project without understanding threads
Yeah, that's an issue. When teaching someone, is it better to let th=
em
do it the simplest, but wrong, way? Or should you teach them to writ=
e
code they don't understand, but promise too "explain it later?"
I'm actually in the latter camp at the moment. I'd rather see you co=
py
and paste good code, than let you get into the habit of writing bad c=
ode
that you feel you understand. It a style of learning thing, more tha=
n a
programming thing, but I think it's better to get you into the habit =
of
looking at correct code now, so it doesn't seem strange when you see =
the
correct version later.
OTOH, it's not going to adversely effect your small programs. The
chance of you hitting a threading error in such a small program is
virtually nil. Just be aware that: 1. the code really is wrong, and =
2.
you'll have to learn threads eventually.
They've already hit a threading error.
How is that "virtually nil" chance?
Usually "hit [by] an error" means actually impacted by the error.
I did not see any case of such.
Have you run the OP's code?
On a multi-processor system?
I had not.
Now I have.
I expect OP to have too.
The chance of actually getting a problem by starting
the GUI in main thread instead of event thread is pretty
small.
Otherwise the wrong way of doing it would not have
been used for so many years.
Not so. Those many years, Swing programs were running on single-
processor machines for the most part. Cache coherency and such
issues were non-existent. Nowadays many machines are multi-processor
and thread bugs are more likely to be visible.
If it were so safe, then it wouldn't be "the wrong way of doing it".
You are expressing the great bad approach to the concurrency problem:
"I don't see a problem in the last two or three times I ran the program,
therefore there is no problem."
This is the attitude that foments so many concurrency bugs.
Concurrency bugs by nature are intermittent, unpredictable and
inconsistent. Your test proves nothing except that you have fallen into
a classic trap.
OP: Don't learn the wrong way. Learn the right way. The fact you don't
see a bug in the first two or dozen times you run the program means
nothing with concurrency issues.
Rule for Swing: DO GUI ACTIONS ONLY ON THE EDT!
That's that.
--
Lew