returning somthing from a thread
Hi all...
I am new to Threads, and I want to know how can I return something from a thread?
For example, if I want to return a string from a normal class I do this:
private String test (String input){
String output = (input + "Hello World");
return output;
}
Nice and easy... the problem with threads though, is the method is always:
new Thread()
{
public void run()
{
if I try to change it to "public String run()[)" the IDE says it needs to be void!
So how can I return somtehing from a thread?
I think you're a bit confused. First of all, just to make things clear, I suppose you meant "method" not "class" ("...if I want to return a string from a normal class..."). A class is basically a factory of objects which may also contain static (non-object related) content. Anyway, back to your question, a thread is just a thread of execution in your program. In Java, when you want to create a thread, you may pass an object implementing the Runnable interface which this thread will run. The thread runs the Runnable , by calling it's run() method (defined:
public void run()
). If you'd like to do anything else in the runnable, feel free to add methods returning whatever you need (i.e, a String). Oh and by the way, you can get the same effect by extending the Thread class and adding your own run() method.
hmm..
my Thread is inside a method, so I need a way to pass data out of the thread, through its pearant method, back to its original calling method...
So Its like this:
MAIN CLASS
-METHOD1
-METHIOD2 WITH THREAD IN
Method 1 calls method 2, and needs to get a String back from method 2... the string is created inside the Thread inside method 2... I need to get that string back to method1...
Well, why not have your first thread call a method defined in your second thread. Consider, for example, you have a running thread containing a method called getString() which returns a string. Now, you're free to call getString() from the first thread, and use whichever String you might get.
Edit- I just read your response. Listen, you're getting things the wrong way around. A thread is not "inside" a method, even though you may create it there. Please have a look at : http://java.sun.com/docs/books/tutorial/essential/concurrency/
Thanks for your replies... I'm reading that tutorial....Sorry for my ignorance.. I get frustrated because the concept still has not "clicked" yet...
> (i.e, a String). Oh and by the way, you can get the
> same effect by extending the Thread class and adding
> your own run() method.
But it's almost always incorrect to do so, because you're usually not creating a new kind of Thread. Thread should not have been made to implement Runnable in the first place. That was a design error on Sun's part, IMHO.
jverda at 2007-7-12 22:32:32 >
> hmm..
>
> my Thread is inside a method, so I need a way to pass
> data out of the thread, through its pearant method,
> back to its original calling method...
>
> So Its like this:
>
>MAIN CLASS
>-METHOD1
> -METHIOD2 WITH
> THREAD IN
>
> Method 1 calls method 2, and needs to get a String
> back from method 2... the string is created inside
> the Thread inside method 2... I need to get that
> string back to method1...
So, is method1 going to stop and wait for the thread to finish? If so, why are you creating another thread?
jverda at 2007-7-12 22:32:32 >
> But it's almost always incorrect to do so, because
> you're usually not creating a new kind of Thread.
> Thread should not have been made to implement
> Runnable in the first place. That was a design error
> on Sun's part, IMHO.
Jverd
Do you mind explaining more? I'm still "green" when it comes to threads. I have just recently read about being able to either subclass Thread or implement Runnable. Are you saying that we should always do the latter? and if so, why? Thanks in advance.
> > But it's almost always incorrect to do so, because
> > you're usually not creating a new kind of Thread.
> > Thread should not have been made to implement
> > Runnable in the first place. That was a design
> error
> > on Sun's part, IMHO.
>
> Do you mind explaining more? I'm still "green" when
> it comes to threads.
It's not about threads so much as about proper use of inheritance.
A Thread is something that the VM associates with a thread of execution and that runs a Runnable. You would extend Thread if you were making a special kind of Thread class with different or enhanced behavior. If all you're doing is defining a task that will be run in a separate thread--which is almost always the case--then you should just implement Runnable. There's no reason to extend Thread.
Thread itself should not be Runnable, since a Thread's job is what I described above, not to be a task that runs in a separate thread.
> I have just recently read about
> being able to either subclass Thread or implement
> Runnable. Are you saying that we should always do
> the latter?
Yes. Unless you're enhancing or modifying Thread's functionality, which you'll probably never do.
jverda at 2007-7-12 22:32:32 >
> It's not about threads so much as about proper use of> inheritance.......Thanks. That helps.
now I have a headache...to give you an idea of what I am trying to do.. see this: http://forum.java.sun.com/thread.jspa?messageID=9748036�(sorry for the double post... I posted my question there too...)
> now I have a headache...
>
> to give you an idea of what I am trying to do.. see
> this:
> http://forum.java.sun.com/thread.jspa?messageID=974803
> 6?
>
> (sorry for the double post... I posted my question
> there too...)
That doesn't answer my questions.
Do you plan on having the method that creates the thread stop and wait for that thread to finish? If so, why are you using a separate thread?
jverda at 2007-7-12 22:32:33 >
well, the only reason for the threads, is because if you look at that page I linked to,you'd see that everything is threaded in that code snippet, because of the way it handles the system calls...
I would rather it not be threaded at all, but the method has to pause, and wait for a response before continuing...
ok.. I am a noob....I misread the code.. it does not need to stop at all....you may flame when ready...(I've removed the thread...)
> well, the only reason for the threads, is because if
> you look at that page I linked to,you'd see that
> everything is threaded in that code snippet, because
> of the way it handles the system calls...
I'm not going to do that. However, if you're talking about Runtime.exec, and stream gobblers, then okay, that makes sense.
Having your main thread kick off one other thread and then wait for that second thread to die makes no sense. That's just sequential programming with an extra thread for no good reason.
Having your main thread kick off multiple other threads that can run independently of each other, and then waiting for them all to die (using join()) makes more sense. First one thing is happening at a time, then multiple things are happening concurrently (e.g. gobbling two different streams), then when those multiple things are done, we go back to one thing at a time.
jverda at 2007-7-12 22:32:33 >
> ok.. I am a noob....
>
> I misread the code.. it does not need to stop at
> all....
So, the main thread continues on its way while the other thread(s) run? That's fine. However, then when you talk about returning a value from the other thread(s) to the main thread, you have to realize that you don't know which code the main thread will be executing when the other threads finish. You'll have to set a variable that the main thread will check at some point.
> you may flame when ready...
No flaming. I'm just trying to give you hints to get you to think about what you're doing and why, and how threads interact.
> (I've removed the thread...)
Um, wait, you said main does NOT need to stop and wait for the other stuff? Then that sounds like multithreading.
jverda at 2007-7-21 23:01:36 >
