Hello, My application has a class that does some processing on a file. Within this class I spawn a new Thread each time the processing method is run.
In the main class this method is invoked when I select a file. I was having some gui flickering issues so I created another thread in the main class when the processing method is called...
Should I create the new thread in the main class or should I leave the thread work in the class that owns the method? Right now I am creating 2 threads to do 1 job. Is there a way where I can create just 1 thread throughout the life of the program that will always run this method? Thanks for your help. [ March 01, 2004: Message edited by: Chris Ramsey ] [ March 01, 2004: Message edited by: Chris Ramsey ]
seems like too many threads. Why not just show a dialog telling the user to please wait while the file loads. that is better than trying to act like nothing is happening. Just tell the truth I think the preferred method would be to create a file load thread. then keep it running. when you need it, send a file into it, then call a process method. it will wake up, load the file, then go back to sleep till it gets another file. use a while loop inside the main method to keep it running, but keep it sleep while its not processing anything.
Joined: Sep 15, 2003
Thanks CL. Sounds good. How to do it is another issue. How do you I keep a thread alive when its not doing anything? Does that take up a lot of memory? Could you show me an example or direct me to a reference that illustrates your suggestion. Thanks for the help. [ March 02, 2004: Message edited by: Chris Ramsey ]
The Jakarta Commons Thread Pool shows one way to keep a thread alive while doing nothing. A thread tries to get a command from a queue. If there are no commands in the queue, the queue blocks until a command is added. When a command is added (or if there was already one there) the queue returns the command to the thread and the thread executes it. The blocking queue is a bit tricky, but the one in the Jakarta package is very easy to read. Just in case it's not familiar ... I'm using "command" in the Gang of Four pattern book sense. It's an object that encapsulates some behavior. You call execute() (for example) and it does whatever behavior it was written to do. The thread pool requires all commands to implement an interface with an execute() method (or run() or something like that) so the thread pool can simply call execute() without knowing anything about what the command does. The Timer class in the JDK shows another way to keep a thread alive but idle. You give it a command and a schedule, and it calls wait() until the next scheduled run. It has some very cool abilities around regularly scheduled jobs. If that was all clear as mud, just holler for more details. [ March 02, 2004: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Sep 15, 2003
Stan, Thanks for the response. I am drooling for more details! I have never been to the Jakarta Commons site before. Thanks for the reference. It said there were no Thread Pool releases. Do you know of another way to them? From what you described its possible to have a thread listening for commands to run, right? This is definitely something I would like to further investigate. Thanks for the help.