Looping in main vs. making a class and a thread?

[Tim Smith]

I've seen quite a few examples where main() pretty much just makes an
instance of some class, and then creates a thread and sets the thread to
running the run() method of the aforementioned class, and then main is
done. The only thing of substance in the aforementioned class is the
run() method, which does some kind of loop acquiring work to do. When
it acquires work, it makes an instance of some second class, which
actually does the work.

Is there actually a good reason to have a class whose sole function is
to run a loop in a thread, as opposed to just running that loop in
main()?

For example, a network server might have a class that just loops in a
thread, accepting connections on a listening socket, and then
instantiating some processing class for each accepted connection.
Why not just have main() create the listening socket, and then loop
accepting connections, doling them out to new instances of a processing
class?

 

[Roedy Green]

Is there actually a good reason to have a class whose sole function is
to run a loop in a thread, as opposed to just running that loop in
main()?

If you have two CPUs, one can do Swing and the other the work of the
spun off thread. Without that, you can't get any parallelism.

 

[Lasse Reichstein Nielsen]

If you have two CPUs, one can do Swing and the other the work of the
spun off thread. Without that, you can't get any parallelism.

That would hold too, if you run the loop in the main thread.

I see no reason to spawn another thread to do some work, and then
stop the current thread immediately afterwards ... unless the new
thread is in some way different (e.g., belongs to a threadgroup
with an uncaught exception handler or something).
/L

 

[Lew]

That would hold too, if you run the loop in the main thread.

I see no reason to spawn another thread to do some work, and then
stop the current thread immediately afterwards ... unless the new
thread is in some way different (e.g., belongs to a threadgroup
with an uncaught exception handler or something).

Most of the examples of the type the OP described that I've seen have been
Swing programs, where the idiom is used to guarantee that Swing work is done
on the EDT. This particular scenario requires that idiom because GUI work
must be done on the EDT, and the EDT is not the main thread.

 

[Mark Rafn]

I've seen quite a few examples where main() pretty much just makes an
instance of some class, and then creates a thread and sets the thread to
running the run() method of the aforementioned class, and then main is
done.

That's my recommendation for commandline apps. I tend to do argument parsing
and error checking in main, and pass the relevant args to the class that does
the work.

Is there actually a good reason to have a class whose sole function is
to run a loop in a thread, as opposed to just running that loop in
main()?

Flexibility. What happens when you want another program to be able to run
that loop? If it's in a main(String[] args) method, the other program is
going to have to give it String arguments in a command-line-like way. If it's
a separate function, it can just be run normally.

Most nontrivial commandline apps will eventually be useful in some sort of
container, rather than being stuck on the commandline forever.

Note that there's not necessarily a reason to have a separate class - as long
as the work functionality isn't in the main() method, it can be in the same
class. The decision of separating the class will depend on size, use cases,
etc. I generally split the class if there's significant argument processing
and error checking the commandline use case needs and the inside-other-app
case doesn't.

 

[Robert Klemme]

That's my recommendation for commandline apps. I tend to do argument parsing
and error checking in main, and pass the relevant args to the class that does
the work.

For that you do not necessarily need a second thread.

Is there actually a good reason to have a class whose sole function is
to run a loop in a thread, as opposed to just running that loop in
main()?

Flexibility. What happens when you want another program to be able to run
that loop? If it's in a main(String[] args) method, the other program is
going to have to give it String arguments in a command-line-like way. If it's
a separate function, it can just be run normally.

Most nontrivial commandline apps will eventually be useful in some sort of
container, rather than being stuck on the commandline forever.

Note that there's not necessarily a reason to have a separate class - as long
as the work functionality isn't in the main() method, it can be in the same
class. The decision of separating the class will depend on size, use cases,
etc. I generally split the class if there's significant argument processing
and error checking the commandline use case needs and the inside-other-app
case doesn't.

You talk about modularization, but the OP wanted to know about
concurrency. Both concepts are orthogonal i.e. you can have one without
the other and vice versa.

Cheers

robert