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

Thread view:

Tim Smith - 12 Jan 2008 06:54 GMT

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?

Signature

--Tim Smith

Reply to this Message

Roedy Green - 12 Jan 2008 09:10 GMT

On Fri, 11 Jan 2008 22:54:07 -0800, Tim Smith
<reply_in_group@mouse-potato.com> wrote, quoted or indirectly quoted
someone who said :

>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.

Signature

Roedy Green, Canadian Mind Products
The Java Glossary, http://mindprod.com

Reply to this Message

Lasse Reichstein Nielsen - 12 Jan 2008 09:55 GMT

> On Fri, 11 Jan 2008 22:54:07 -0800, Tim Smith
> <reply_in_group@mouse-potato.com> wrote, quoted or indirectly quoted
[quoted text clipped - 6 lines]
> 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

Signature

Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Reply to this Message

Lew - 12 Jan 2008 13:59 GMT

>> On Fri, 11 Jan 2008 22:54:07 -0800, Tim Smith
>> <reply_in_group@mouse-potato.com> wrote, quoted or indirectly quoted
[quoted text clipped - 12 lines]
> 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.

Signature

Lew

Reply to this Message

Mark Rafn - 12 Jan 2008 19:32 GMT

>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.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>

Reply to this Message

Robert Klemme - 13 Jan 2008 11:35 GMT

>> 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
[quoted text clipped - 4 lines]
> 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
[quoted text clipped - 14 lines]
> 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

Reply to this Message

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

Free Magazines